NAVAL 

POSTGRADUATE 

SCHOOL 

MONTEREY,  CALIFORNIA 


THESIS 


TAILORING  SYSTEMS  ENGINEERING  PROCESSES  FOR 
RAPID  SPACE  ACQUISITIONS 

by 

Kipp  Johnson 
September  2010 

Thesis  Co-Advisors:  John  Osmundson 

Joseph  DeVenuto 


Approved  for  public  release;  distribution  is  unlimited 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


j  REPORT  DOCUMENTATION  PAGE 

Form  Approved  OMB  No.  0704-0188  f 

Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instruction, 
searching  existing  data  sources,  gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send 
comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information,  including  suggestions  for  reducing  this  burden,  to 
Washington  headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington,  VA 
22202-4302,  and  to  the  Office  of  Management  and  Budget,  Paperwork  Reduction  Project  (0704-0188)  Washington  DC  20503. 

1.  AGENCY  USE  ONLY  (Leave  blank) 

2.  REPORT  DATE 

September  2010 

3.  REPORT  TYPE  AND  DATES  COVERED 

Master’s  Thesis 

4.  TITLE  AND  SUBTITLE 

Tailoring  Systems  Engineering  Processes  for  Rapid  Space  Acquisitions 

5.  FUNDING  NUMBERS 

6.  AUTHOR(S)  Kipp  Johnson 

_ 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Naval  Postgraduate  School 

Monterey,  CA  93943-5000 

8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 

9.  SPONSORING  /MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

N/A 

10.  SPONSORING/MONITORING 
AGENCY  REPORT  NUMBER 

11.  SUPPLEMENTARY  NOTES  The  views  expressed  in  this  thesis  are  those  of  the  author  and  do  not  reflect  the  official  policy 
or  position  of  the  Department  of  Defense  or  the  U.S.  Government.  IRB  Protocol  number:  N/A. 

12a.  DISTRIBUTION  /  AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  is  unlimited 

12b.  DISTRIBUTION  CODE 

1  13.  ABSTRACT  (maximum  200  words) 

The  Self-Awareness  Space  Situational  Awareness  (SASSA)  program  is  a  congressionally  initiated  technology 
demonstration  program  run  by  the  Air  Force,  Space  and  Missile  System  Center  (SMC),  Los  Angeles  Air  Force  Base. 
Initiated  October  2008,  SASSA  is  investigating  the  feasibility  of  a  highly  flexible  and  adaptable  satellite  payload 
system  for  detecting  satellite  threats,  both  natural  and  manmade.  The  SASSA  program  was  given  cost  and  schedule 
limitations  with  a  mandate  to  deliver  hardware  for  demonstration  in  24  months,  considered  a  “rapid  acquisition”  by 
AF  and  SMC  standards.  This  study  provides  an  assessment  of  how  the  SASSA  program  tailored  systems  engineering 
processes  to  implement  a  “rapid  space  acquisition.”  Acquisition  and  engineering  standards  define  a  roadmap  for 
military  procurements  to  produce  the  most  effective  product  at  the  most  reasonable  cost.  Refinement  of  these 
standards  over  time  is  critical  to  the  continued  success  of  acquisition  systems  to  evolve  a  current  and  effective 
military.  This  study  reviews  the  SASSA  concept  and  technology  demonstration,  surveys  standard  systems  engineering 
guidance,  catalogues  systems  engineering  processes  tailored,  and  assesses  effectiveness  of  this  tailoring.  This  study 
will  provide  observation  and  assessment  of  real-world  results,  successful  and  unsuccessful,  for  the  purposes  of 
capturing  and  documenting  lessons  learned  towards  successfully  accomplishing  rapid  space  acquisitions. 

14.  SUBJECT  TERMS 

Systems  Engineering,  Rapid  Acquisitions,  Space,  Satellite  Payload,  Space  Situational  Awareness,  Air 
Force,  Technology  Demonstration,  Lessons  Learned 

15.  NUMBER  OF 

PAGES 

119 

16.  PRICE  CODE 

17.  SECURITY 
CLASSIFICATION  OF 
REPORT 

Unclassified 

18.  SECURITY 

CLASSIFICATION  OF  THIS 
PAGE 

Unclassified 

19.  SECURITY 
CLASSIFICATION  OF 
ABSTRACT 

Unclassified 

20.  LIMITATION  OF 
ABSTRACT 

UU 

NSN  7540-01-280-5500  Standard  Form  298  (Rev.  2-89) 


Prescribed  by  ANSI  Std.  239-18 


1 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


11 


Approved  for  public  release;  distribution  is  unlimited 


TAILORING  SYSTEMS  ENGINEERING  PROCESSES  FOR  RAPID  SPACE 

ACQUISITIONS 


Kipp  M.  Johnson 
Captain,  United  States  Air  Force 
B.S.,  University  of  Colorado,  2000 


Submitted  in  partial  fulfillment  of  the 
requirements  for  the  degree  of 


MASTER  OF  SCIENCE  IN  SYSTEMS  ENGINEERING  MANAGEMENT 


from  the 


NAVAL  POSTGRADUATE  SCHOOL 
September  2010 


Author:  Kipp  M.  Johnson 


Approved  by:  John  Osmundson 

Thesis  Co-Advisor 


Joseph  DeVenuto 
Thesis  Co-Advisor 


Cliff  Whitcomb 

Chairman,  Department  of  Systems  Engineering 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


IV 


ABSTRACT 


The  Self-Awareness  Space  Situational  Awareness  (SASSA)  program  is  a  congressionally 
initiated  technology  demonstration  program  run  by  the  Air  Force,  Space  and  Missile 
System  Center  (SMC),  Los  Angeles  Air  Force  Base.  Initiated  October  2008,  SASSA  is 
investigating  the  feasibility  of  a  highly  flexible  and  adaptable  satellite  payload  system  for 
detecting  satellite  threats,  both  natural  and  manmade.  The  SASSA  program  was  given 
cost  and  schedule  limitations  with  a  mandate  to  deliver  hardware  for  demonstration  in  24 
months,  considered  a  “rapid  acquisition”  by  AF  and  SMC  standards.  This  study  provides 
an  assessment  of  how  the  SASSA  program  tailored  systems  engineering  processes  to 
implement  a  “rapid  space  acquisition.”  Acquisition  and  engineering  standards  define  a 
roadmap  for  military  procurements  to  produce  the  most  effective  product  at  the  most 
reasonable  cost.  Refinement  of  these  standards  over  time  is  critical  to  the  continued 
success  of  acquisition  systems  to  evolve  a  current  and  effective  military.  This  study 
reviews  the  SASSA  concept  and  technology  demonstration,  surveys  standard  systems 
engineering  guidance,  catalogues  systems  engineering  processes  tailored,  and  assesses 
effectiveness  of  this  tailoring.  This  study  will  provide  observation  and  assessment  of  real- 
world  results,  successful  and  unsuccessful,  for  the  purposes  of  capturing  and 
documenting  lessons  learned  towards  successfully  accomplishing  rapid  space 
acquisitions. 


v 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


vi 


TABLE  OF  CONTENTS 


I.  INTRODUCTION . 1 

A.  BACKGROUND . 1 

B.  PURPOSE . 1 

C.  RESEARCH  QUESTIONS . 2 

D.  BENEFITS  OF  STUDY . 2 

E.  SCOPE  AND  METHODOLOGY . 3 

1.  Scope . 3 

2.  Methodology . 3 

F.  SUMMARY  OF  FINDINGS . 4 

1.  Recommendations  for  the  Systems  Engineering  Community . 6 

2.  Recommendations  for  Accomplishing  Rapid  Space 

Acquisitions . 6 

II.  SASSA:  ORIGINS  AND  OVERVIEW  OF  THE  SASSA  PROGRAM . 9 

A.  INTRODUCTION . 9 

B.  THE  SASSA  TECHNOLOGY  DEMONSTRATOR  DESCRIPTION . 10 

1.  Acquisition  Strategy . 10 

2.  Timeline  and  Milestones . 12 

3.  System  Description  Overview . 12 

a.  System  Description . 12 

b.  Space  Segment. . 13 

c.  Ground  Segment . 14 

d.  Testbed . 15 

4.  Program  Summary  and  Current  Status . 15 

III.  STANDARD  SYSTEMS  ENGINEERING  PROCESSES  DISCUSSION . 17 

A.  INTRODUCTION . 17 

B.  GENERAL  SYSTEMS  ENGINEERING  PROCESSES . 17 

C.  SPACE  SYSTEMS  ENGINEERING  PROCESSES . 19 

D.  SYSTEMS  ENGINEERING  GUIDANCE  CATEGORIES . 21 

E.  BODY  OF  AUTHORITATIVE  SOURCES  FOR  SYSTEMS 

ENGINEERING . 23 

F.  SUMMARY . 24 

IV.  DISCUSSION  AND  ANALYSIS  OF  APPLICABLE  STANDARD  SYSTEMS 

ENGINEERING  PROCESSES . 27 

A.  INTRODUCTION . 27 

1.  SASSA  Motivation  for  Tailoring  Standard  Systems 

Engineering  Processes . 27 

2.  Guidance  for  Tailoring  from  Standard  Systems  Engineering 

Sources . 28 

3.  Standard  Systems  Engineering  Processes  Chosen  for  Tailoring 

on  SASSA . 30 

vii 


B.  SASSA  TAILORED  STANDARD  SYSTEMS  ENGINEERING 

PROCESSES . 32 

1.  Requirements  Development . 32 

a.  Description  of  Standard  Requirements  Development. . 32 

b.  SASSA  Tailored  Requirements  Development  as 

Implemented . 37 

c.  Comparison  of  Standard  Systems  Engineering  Guidance 

to  SASSA . 43 

2.  Functional  Architecture  and  Design  Synthesis . 44 

a.  Description  of  Functional  Architecture  and  Design 

Synthesis . 44 

b.  SASSA  Tailored  Functional  Architecture  Design  and 

Synthesis  as  Implemented . 47 

c.  Comparison  of  Standard  Guidance  to  SASSA . 49 

3.  Standard  Systems  Engineering  Plans . 50 

a.  Description  of  Standard  Systems  Engineering  Plans . 50 

b.  SASSA  Tailored  Systems  Engineering  Plans  as 

Implemented . 52 

c.  Comparison  of  Standard  Guidance  to  SASSA . 54 

4.  Use  of  Systems  Engineering  Leads . 55 

a.  Description  of  Systems  Engineering  Leads  From 

Guidance. . 55 

b.  SASSA  Tailored  Systems  Engineering  Leads  as 

Implemented . 55 

c.  Comparison  of  Standard  Guidance  to  SASSA . 56 

5.  Technical  Reviews . 56 

a.  Description  of  Technical  Reviews  From  Guidance . 56 

b.  SASSA  Tailored  Technical  Reviews  as  Implemented. . 60 

c.  Comparison  of  Standard  Guidance  to  SASSA . 64 

6.  Integrated  Product  Team  (IPT)  Structures . 65 

a.  Description  of  Integrated  Product  Teams  (IPT)  in 

Standard  SE  Sources . 65 

b.  SASSA  Tailored  IPT  Structure  as  Implemented . 6  7 

c.  Comparison  of  Standard  Guidance  to  SASSA . 69 

V.  EVALUATION  OF  SASSA  TAILORED  SYSTEMS  ENGINEERING 

PROCESSES . 71 

A.  INTRODUCTION . 71 

B.  STANDARD  CRITERIA  FOR  EVALUATING  TAILORED 

PROCESSES . 71 

C.  SASSA  TAILORED  SYSTEMS  ENGINEERING  PROCESSES 

EVALUATION . 72 

1.  Requirements  Development . 72 

2.  Functional  Architecture  Design  and  Synthesis . 73 

3.  Standard  Systems  Engineering  Plans . 74 

4.  Use  of  Systems  Engineering  Leads . 75 


viii 


5.  Technical  Reviews . 76 

6.  Integrated  Product  Team  (IPT)  Structures . 78 

D.  CHAPTER  SUMMARY . 78 

VI.  APPLICATION  OF  STUDY . 81 

A.  INTRODUCTION . 81 

B.  OBSERVATIONS . 81 

C.  RECOMMENDATIONS . 83 

1.  Recommendations  for  the  Systems  Engineering  Community . 83 

2.  Recommendations  for  Accomplishing  Rapid  Space 

Acquisitions . 84 

D.  AREAS  FOR  FURTHER  RESEARCH . 84 

APPENDIX  A.  ACQUISITION  DESCRIPTION  SUMMARY . 85 

APPENDIX  B.  DEFINITION  OF  TERMS . 91 

LIST  OF  REFERENCES . 95 

INITIAL  DISTRIBUTION  LIST . 97 


IX 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


x 


LIST  OF  FIGURES 


Figure  1 .  SASSA  Program  Timeline . 12 

Figure  2.  Relationship  of  Systems  Engineering  Guidance  Sources . 24 

Figure  3.  Tailoring  SE  Processes  (INCOSE  SE  Handbook  Figure  8-1) . 29 

Figure  4.  JCIDS  Process  Overview  (SMC  SE  Primer,  p.  7) . 33 

Figure  5.  Example  of  SASSA  Excel  Traceability  Spreadsheet . 41 

Figure  6.  Simplified  SE  Process  (from  Figure  13  SMC  SE  Primer) . 45 

Figure  7.  Requirements  Analysis  Process  (SMC  SE  Primer  Figure  14) . 46 

Figure  8.  Example  SASSA  Milestone  Review  Schedule . 63 

Figure  9.  Typical  Organizational  Structure . 66 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


LIST  OF  TABLES 


Table  1.  Summary  of  Tailored  Standard  Systems  Engineering  Processes . 5 

Table  2.  Systems  Engineering  Processes  for  Acquisitions . 22 

Table  3.  Systems  Engineering  Guidance  Sources . 23 

Table  4.  The  SASSA  Tailored  Standard  Systems  Engineering  Processes . 3 1 

Table  5.  Systems  Engineering  Parallel  Processes  as  Implemented  in  the  SASSA 

Program . 31 

Table  6.  Systems  Engineering  Serial  Processes  as  Implemented  in  the  SASSA 

Program . 31 

Table  7.  SE  Technical  Management  Processes  as  Implemented  in  the  SASSA 

Program . 31 

Table  8.  SASSA  Functional  Objectives . 38 

Table  9.  Sample  SEP  topics . 51 

Table  10.  Sample  SEMP  topics . 52 

Table  11.  List  of  Program  Milestones  (SV  SE  Handbook,  p.  8) . 58 

Table  12.  SASSA  Events  (SASSA  RFP  Attachment  CD-4,  p.  36) . 60 

Table  13.  SASSA  Significant  Accomplishments  (SASSA  RFP  Attachment  CD-4,  p. 

36) . 61 

Table  14.  SASSA  Milestones  Conducted . 61 

Table  15.  Summary  of  Tailored  Standard  Systems  Engineering  Processes . 79 


xiii 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


xiv 


LIST  OF  ACRONYMS  AND  ABBREVIATIONS 


AoA 

Analysis  of  Alternatives 

AMA 

Analysis  of  Material  Approaches 

ACAT 

Acquisition  Category 

AFRL 

Air  Force  Research  Laboratory 

AFSCN 

Air  Force  Satellite  Control  Network 

AFSPC 

Air  Force  Space  Command 

AF 

Air  Force 

AI&T 

Assembly,  integration,  and  test 

AM 

Antenna  Module 

ASAT 

Anti-Satellite 

ATC 

Assurance  Technology  Corporation  (SASSA  Contractor) 

ATP 

Authority  to  Proceed  (as  in  contract  award) 

CCB 

Change  Control  Board 

CCS 

Command,  Control  and  Status  Subsystem  (SASSA  program) 

CDD 

Capability  Development  Document 

CDR 

Critical  Design  Review 

CDRL 

Contract  Data  Requirements  List 

CIU 

Common  Interface  Unit 

CM 

Configuration  Management 

CONOP(S) 

Concept  of  Operations 

COTS 

Commercial  off  the  Shelf 

cPCI 

Compact  Pre-Con  figured  Interface 

CTE 

Critical  Technology  Elements 

DAG 

Defense  Acquisition  Guidebook 

DAU 

Defense  Acquisition  University 

DoD 

Department  of  Defense 

DoDAF 

Department  of  Defense  Architecture  Framework 

DoDI 

Department  of  Defense  Instruction 

XV 


DOORS 

Distributed  Object  Oriented  Requirements  System 

DOTMLPF 

Doctrine,  Organization,  Training,  Materiel,  Logistics,  Personnel 
and  Facilities 

DPA&E 

Director,  Program  Analysis  &  Evaluation 

DSC 

Dedicated  Stand  alone  Communication 

EDU 

Engineering  Development  Unit 

EIA 

Electronics  Industries  Association 

ERB 

Engineering  Review  Board 

EVMS 

Earned  Value  Management  System 

FFRDC 

Federally  Funded  Research  and  Development  Centers 

FRB 

Failure  Review  Boards 

GAO 

General  Accounting  Office 

GPS 

Global  Positioning  System  (government  program) 

HDMI 

High-Definition  Multimedia  Interface 

HTTP 

Hypertext  Transfer  Protocol 

HW 

Hardware 

ICD 

(1)  Initial  Capability  Document 

(2)  Interface  Control  Document 

ID 

Identification 

IEC 

International  Electrotechnical  Commission 

IEEE 

Institute  for  Electrical  and  Electronics  Engineers 

IMP 

Integrated  Master  Plan 

IMS 

Integrated  Master  Schedule 

INCOSE 

International  Council  on  Systems  Engineering 

IPDT 

Integrated  Product  Development  Teams 

IPT 

Integrated  Product  Team(s) 

ISR 

Intelligence,  Surveillance,  and  Recognizance 

JCD 

Joint  Capabilities  Document 

JCID 

Joint  Capabilities  Integration  and  Development 

JCIDS 

Joint  Capabilities  Integration  and  Development  System 

KDP 

Key  Decision  Point 

XVI 


KPP 

Key  performance  parameter 

KSA 

Key  System  Attribute 

LAAFB 

Los  Angeles  Air  Force  Base 

LEO 

Low  Earth  Orbit 

MAJCOM 

Major  Command  (as  in  Air  Force  Major  Commands) 

MATLAB 

Mathematical  Analysis  Software  (COTS) 

MDA 

Milestone  Decision  Authority 

MDAP 

Major  Defense  Acquisition  Program 

MIL-Spec 

Military  Specification 

MIL- STD 

Military  Standard 

MNS 

Mission  Needs  Statement 

MPA 

Mission  Planning  and  Analysis  Subsystem  (SASSA  program) 

NS  A 

National  Security  Agency 

OIC 

Officer  in  Charge 

PCI 

Pre-Configured  Interface 

PDR 

Preliminary  Design  Review 

PM 

Program  Management 

PMP 

Parts,  Materials,  and  Processes  Plan  or  Parts  Management  Plan 

PO 

Program  Office 

RAA 

Responsibility,  Authority,  and  Accountability 

RF 

Radio  Frequency 

RFP 

Request  for  Proposal 

RSPM 

Receiver  signal  Processor  Module  (SASSA  component) 

RWR 

Radar  Warning  Receiver 

SA 

Situation(al)  awareness 

SASSA 

Self-Awareness  Space  Situational  Awareness 

SSA 

Space  Situational  Awareness 

SC 

Space  Craft 

SDD 

System  Development  and  Demonstration 

SDP 

Software  Development  Plan 

XVII 


SDR 

System  Design  Review 

SE 

Systems  Engineering 

SEDS 

Systems  Engineering  Detailed  Schedule 

SEIT 

System  Engineering  &  Integration  Team 

SEMP 

Systems  Engineering  Management  Plan  (Contractors) 

SEMS 

Systems  Engineering  Master  Schedule 

SEP 

Systems  Engineering  Plan  (Government) 

SETA 

System  Engineering  and  Technical  Assistance 

SIS 

Standard  Interface  Specification  (as  in  SASSA  program  SIS) 

SMC 

Space  and  Missiles  System  Center 

SOH 

State  of  Health 

SOO 

Statement  of  (Government)  Objectives 

SOW 

Statement  of  Work 

SPO 

System  Program  Office 

SRD 

System  Requirements  Document 

SRD 

System  Requirements  Document 

SRR 

System  Requirements  Review 

SRS 

Software  Requirements  Specification 

SSA 

Space  Situational  Awareness 

SSR 

Software  Specification  Review 

SV 

Space  Vehicle 

sw 

Software 

TPM 

Technical  Perfonnance  Measure 

TRD 

Technical  Requirements  Document 

TRL 

Technology  Readiness  Level 

USAF 

United  States  Air  Force 

USB 

Universal  Serial  Bus 

USSTRATCOM 

United  States  Strategic  Command 

WIPT 

Working  level  IPT  (Integrated  Product  Team) 

XML 

Extensible  Markup  Language 

xviii 


ACKNOWLEDGMENTS 


First,  thank  you  to  the  professors  in  the  Systems  Engineering  department  and  in 
the  PD-2 1  program  that  opened  the  world  of  systems  engineering  to  me,  a  career  I  very 
much  enjoy  now  and  plan  to  for  a  long  time.  To  Steve  Leonard,  thank  you  for  betting  that 
giving  up  my  time  from  work  one  day  a  week  would  pay  off  in  the  long  run.  I  finally 
proved  you  right!  To  Mark  Rhoades,  Tom  Hunyh,  and  Heather  Hahn,  thank  you  for  all 
your  combined  efforts  and  help  to  get  me  to  the  end,  we  finally  did  it!  To  Professor  John 
Osmundson,  thank  you  for  being  willing  to  take  me  on  as  thesis  student  and  all  your 
efforts  along  the  way,  you  made  the  difference.  To  Pam  Silva  and  Janis  Higginbotham, 
your  excellence  and  encouragement  kept  my  spirits  up  in  the  toughest  of  times.  I  could 
not  have  stayed  sane  nor  done  this  without  you.  To  Capt  M.  Leon  Killings,  thank  you  for 
caring  enough  to  run  a  good  program,  and  having  the  courage  to  lead  and  not  follow  the 
course  of  mediocrity.  To  Joe,  what  else  can  you  say  except  thank  you  to  someone  who 
answers  all  your  questions,  shows  you  the  path  of  excellence  on  the  job,  and  takes  the 
time  to  mentor  and  teach  along  the  way?  You  made  a  difference  in  my  life  and  career  and 
your  help  on  this  study  was  vital.  And,  most  importantly  to  my  wife,  you  patiently  waited 
for  three  years  for  me  to  get  this  study  done  in  my  own  time  and  way,  through  three 
different  topics.  You  put  up  with  me  on  tired  days  and  late  nights  and  did  not  complain 
when  it  was  just  taken  for  granted  that  every  spare  moment  was  to  be  spent  in  front  of  the 
computer.  You  mean  the  world  to  me  and  have  always  challenged  me  to  be  the  best  man 
and  husband  I  could  be.  With  all  my  heart,  thank  you.  I  am  eternally  grateful. 


xix 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


xx 


I.  INTRODUCTION 


A.  BACKGROUND 

Spurred  by  the  2007  Chinese  Anti- Satellite  (ASAT)  event,  the  Self  Awareness 
Space  Situational  Awareness  (SASSA)  technology  demonstration  program  was 
established  to  evolve  the  concept  of  Space  Situational  Awareness  (SSA),  which  would 
address  local  satellite  awareness,  as  well  as  contribute  to  global  awareness  of  space 
objects.  SASSA  has  also  sought  to  find  a  reasonable  path  for  a  more  pervasive  and 
accessible  solution  to  local  satellite  threat  warning,  versus  current  satellite-specific 
implementations.  The  SASSA  program  utilizes  the  paradigm  that  an  understanding  of  the 
local  threat  environment  enables  the  possibility  of  action  towards  threat  protection.  A 
potential  solution  being  demonstrated  by  SASSA  is  to  develop  adaptable  and  flexible 
space  and  ground  elements  whose  primary  aspects  remain  the  same  while  peripherals  are 
adapted  to  specific  threat  warning  needs.  This  concept,  once  matured,  may  lead  to  a  “one- 
size-fits-most”  product  line  for  threat  warning  systems.  Conceptually  the  SASSA 
architecture  would  be  capable  of  integrating  various  threat  warning  sensor  suites  with 
well-defined  standard  interfaces  on  satellite  vehicles.  This  concept  applied  across  the 
U.S.’  space  assets  could  dramatically  increase  our  understanding  of  the  natural  and 
manmade  space  environment,  ultimately  enabling  significantly  enhanced  protection 
capabilities  for  our  national  space  assets. 

B.  PURPOSE 

This  thesis  describes  and  evaluates  the  tailoring  of  SE  guidance  for  DoD 
acquisitions  for  a  smaller,  rapid  space  acquisition  program.  An  inherent  assumption  is 
that  there  is  a  standard  body  of  systems  engineering  guidance  provided  to  the  DoD 
community  from  which  to  develop  and  draw  direction  for  how  to  implement  and  apply 
systems  engineering  practices  to  such  a  program.  This  study  captures  and  assesses 


1 


tailored  systems  engineering  guidance  and  documents  lessons  learned,  applicable  to  like 
systems  in  the  future,  for  effectively  supporting  the  delivery  of  a  rapid-paced  space 
satellite  payload  acquisition. 

C.  RESEARCH  QUESTIONS 

The  goal  of  this  study  is  to  use  the  SASSA  program  as  a  case  study  for  the 
effectiveness  of  tailoring  standard  systems  engineering  processes  such  as:  developing 
objectives,  requirements,  specifications,  milestones  reviews,  assembly,  integration  and 
test  (AI&T),  and  validation/  verification  of  requirements  in  order  to  support  the  delivery 
of  a  rapid  pace,  cost  constrained  satellite  payload  acquisition.  The  study  questions 
investigated  are  as  follows: 

1)  What  are  the  standard  systems  engineering  guidance  sources  available  and  expected  to 
be  used  by  DoD  space  program  systems  engineers? 

•  Means  to  find  answer:  Perform  survey  of  DoD  and  industry  standard  systems 
engineering  guidance  sources  available  to  DoD  space  program  systems  engineers. 

2)  What  are  the  standard  systems  engineering  processes  that  SASSA  effectively  tailored 
to  be  more  effective  for  rapid  acquisitions? 

•  Means  to  find  answer:  Observations/results  from  actual  program,  quantifiable  data 
from  program  where  possible. 

3)  Study  Questions:  What  are  the  standard  systems  engineering  processes  that  SASSA 
did  not  effectively  modify  to  be  more  effective  for  rapid  acquisitions? 

•  Means  to  find  answer:  Observations/results  from  actual  program,  quantifiable  data 
from  program  where  possible. 

D.  BENEFITS  OF  STUDY 

This  study  provides  a  listing  of  DoD  and  industry  standard  systems  engineering 
sources  recommended  to  government  personnel  in  perfonning  systems  engineering  on 
DoD  space  programs.  This  list  of  sources  comprises  the  body  of  source  material,  which 
defines  “standard”  SE  processes.  This  provides  a  context  for  the  observation  and 
assessment  of  real  world  results  in  the  implementation  of  tailored  standard  SE  processes, 
both  successful  and  unsuccessful.  This  is  hoped  to  benefit  process  innovation  of  standard 
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systems  engineering  guidance  and  standards  in  the  DoD  acquisition  framework,  which  is 
critical  to  the  continued  success  and  optimization  of  acquisition  systems  to  sustain  a 
current  and  effective  military.  It  may  also  benefit  other  military  acquisitions  which  are  of 
similar  size  and  pace,  especially  rapid  space  acquisitions  by  observing  actual  tailored 
processes  implemented  and  their  lessons  learned.  Specifically,  this  thesis  supports  this 
through  providing: 

a)  A  listing  of  standard  systems  engineering  guidance  for  DoD  space  programs 

b)  Real  world  examples  of  tailored  SE  processes  for  rapid  space  payload 
acquisitions 

c)  Evaluation  of  these  processes  for  effectiveness  towards  rapid  space  acquisition 

d)  Observations  and  recommendations  for  improving  SE  processes  for  space 
acquisitions  particularly  rapid  space  acquisitions 

E.  SCOPE  AND  METHODOLOGY 

1.  Scope 

The  scope  of  this  thesis  topic  is  limited  to  identifying  and  analyzing  systems 
engineering  processes  that  have  already  been  accomplished  on  an  Air  Force  satellite 
payload  acquisition  from  summer  2007  to  present  (currently  post  CDR).  Firsthand 
experience  provided  from  the  researcher  as  well  as  other  participants  in  the  government 
program  management  and  technical  oversight  team  are  used. 

2.  Methodology 

The  approach  to  accomplishing  this  study  involved  four  phases.  The  first  phase  of 
this  study  started  with  a  survey  of  industry  and  DoD  standard  systems  engineering 
guidance  documents  to  define  a  set  of  authoritative  systems  engineering  source  material. 
Once  a  body  of  authoritative  material  for  SE  guidance  was  established,  then  a  survey  of 
this  material  was  conducted  to  find  areas  where  the  SASSA  program  tailored  their  SE 
practices. 

The  second  phase  compared  and  identified  areas  of  difference  between 
authoritative  SE  guidance  identified  and  processes  implemented  in  the  SASSA  program. 
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A  catalogue  of  standard  SE  processes  which  were  tailored  for  SASSA  was  created.  The 
discussion  includes  a  description  of  the  standard  guidance  from  the  authoritative  source 
documents,  the  corollary  process  implemented  by  SASSA,  and  an  identification  of  the 
differences  between  the  two. 

The  third  phase  utilized  the  data  identified  in  phase  two  for  tailored  processes  and 
attempted  to  assess  whether  or  not  each  process  implemented  was  successful  or 
unsuccessful  towards  achieving  the  goal  of  a  rapid  space  payload  acquisition.  For  each 
process,  a  case  was  presented  either  advocating  for  or  against  the  process  implementation 
as  effective  or  not  effective. 

The  final  phase  of  the  study  included  capturing  the  conclusions  drawn  in  the 
previous  phases.  The  final  chapter  focused  on  the  applications  of  the  study.  This  started 
by  discussing  recommendations  for  changes  to  standard  guidance  as  a  result  of  the 
research  gathered  in  this  study.  The  next  section  was  a  collection  of  recommendations  for 
programs  that  have  similar  characteristics  to  the  SASSA  program  in  size  or  pace  for 
achieving  a  rapid  acquisition. 

F.  SUMMARY  OF  FINDINGS 

The  completion  of  this  study  has  yielded  an  assessment  of  the  effectiveness  of 
tailored  SE  processes  on  the  SASSA  program  in  achieving  the  cost,  schedule,  and 
technical  goals  in  a  rapid  space  acquisition.  This  study  assessed  six  standard  SE  processes 
as  tailored  by  the  SASSA  program.  Of  these  six,  one  was  judged  as  a  neutral  contribution 
while  five  were  judged  as  helpful  in  achieving  the  program  goals.  No  tailored  processes 
were  judged  as  negative  contributions  to  meeting  the  rapid  space  acquisitions  goals. 
These  results  are  summarized  in  Table  1. 


Modified  SE 
Process 

SASSA  Modifications 

Benefits 

Risks 

Contribution 

Requirements 

Development 

-  No  JCIDS  process 
involvement/  utilization 

-  No  formal  stakeholder 
involvement 

-  No  KPP/KPA’s 

-  Strong  traceability 
from  goals  to  req.’s 

-  Clear  traceability 
from  original  goals 
to  req.’s 

-  Allowed  program 
to  move  more 
quickly  than  a  JCIDs 
program 

-  Potential  lack  of 
insight  into  final 
capability  with  no 
interim  KPP/KPA 

assessment 

-  Output  capability  of 
program  not  useful  to 

Positive 
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users  (potential) 

Modified  SE 
Process 

SASSA  Modifications 

Benefits 

Risks 

Contribution 

Functional 
Architecture 
and  Design 
Synthesis 

-  Gov  imposed  design 
aspects  (TRL,  HW 
units,  heritage  req.’s) 

-  Defined  Functional 
elements  -  Minimize 
inefficient/wasted 
design  effort 

-  Focus  program  on 
likely  solutions 

-  High  probability  of 
plausible  options 

-  Miss  inventive  or 
creative  solutions 

-  “Constrain  out” 
better  solution 

Positive 

Standard  SE 
Plans 

-  No  government  or 
contractor  SEP,SEMP, 
SEMS,  or  SEDS 
-Use of RFP,  IMS, 
CDRLs  for  SE  process 

-  Program  meetings  to 
define  processes 

-  Use  of  Contractor 
processes 

-  Saved  resources  for 
Gov  and  contractor 

-  Less  documentation 

-  Less  overall  tasks 

-  Gov  does  not  see 
potential  deficient  SE 
plans  of  contractor 

-  Gov  is  unclear  on 
its  own  SE 
plans/process 

Positive 

Use  of 

Systems 

Engineering 

Leads 

-  No  dedicated  SE  lead 
on  government  team 

-  Team  SE  process 

-  More  than  one  SE 

-  Diverse, 
collaborative  SE 
tracking 

-  Lack  of  adequate 

SE 

-  Inconsistent  SE 
process 

-  Critically  dependant 
on  team  composition 

Neutral 

Technical 

Reviews 

-  SRR  before  IBR 

-  Entry/Exit  criteria  not 
generated  before 
program  initiation 

-  Criteria  not  in 

SEM(P) 

-  No  completely 
independent  reviewers 

-  No  incremental 

reviews 

-  Superior 
knowledge  of 
program 
requirements  for 
baseline  planning 

-  Understand 
program  needs  from 
the  start 

-  Save  resources 

-  Thorough  reviews 

-  Contractor  not 
understanding  tech 
event  criteria  in 
planning  resources 
for  baseline 

-  Under  scope 
resources 

-  Too  much  in  one 
review  for  larger 
programs 

-  Miss  independent 
perspective 

Positive 

Integrated 

Product 

Teams  (IPT’s) 

-  “Flat”,  versatile 
government  team 
structure  vice  IPT 
structure 

-  More  expertise 
exposed  to  more 
tasks 

-  surge  capability  for 
quick  task 
completion 

-  Entire  team  up  to 
date  on  critical  issues 

-  Counteracts  stove 
piped  thinking 

-  Good  fit  for 
minimal  Gov 

resources 

-  Entire  team  aware 
of  program  status 

-  Too  much 
information  for  all  to 
absorb  as  program 
grows 

-  Lack  of  ability  to 
have  needed  depth  in 
focused  area  in  large 
programs 

-  Lack  of  consistent 
follow 

through/tracking  of 
single  segment  issues 

Positive 

Table  1.  Summary  of  Tailored  Standard  Systems  Engineering  Processes 
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These  conclusions  lead  the  researcher  to  have  recommendations  for  the 
application  of  the  study: 

1.  Recommendations  for  the  Systems  Engineering  Community 

•  Perfonn  a  survey  of  SE  guidance  for  military  acquisitions  and  ensure  there  is 
comprehensive  coverage  of  SE  processes  (as  opposed  to  SE  technical 
management). 

o  Publish  a  Primer  which  points  to  or  consolidates  this  “how  to  do  SE  in  the 
military”  for  ease  of  use  and  proliferation 

•  Create  a  new  SE  guidance  or  append  the  present  guidance  which  would  instruct 
on  how  to  practically  implement  and  accomplish  SE  processes  on  non-formal/ 
non  JCID’s  programs 

•  Create  a  new  SE  guidance  or  append  the  present  guidance  for  recommendations 
on  how  to  tailor  standard  guidance  for  non-formal/  non  JCID’s  programs 

o  Address  the  importance  and  relationship  of  the  large  number  of  small 
technology  and  acquisition  efforts  to  the  larger  formal  programs  and 
JCIDS  process.  Good  SE  is  needed  even  in  these  small  programs  to  be 
efficient  in  technology  maturation  as  it  relates  to  larger  programs 

•  Continue  to  instruct  in  basic  SE  application  and  build  a  strong  foundational 
knowledge  of  accomplishing  SE  processes  in  SE  students 

o  Advocate  for  high  levels  of  practical  implementation  instruction  for  doing 
SE  in  military  programs  at  universities  and  especially  in  military  higher 
education  facilities 

2.  Recommendations  for  Accomplishing  Rapid  Space  Acquisitions 

•  Observe  and  consider  the  positive  contributions  made  on  the  SASSA  program  by 
tailoring  standard  SE  guidance 
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•  Tailor  standard  SE  guidance  and  choose  quality  teams  using  “value  added”  as  a 
prime  criteria 

•  Ensure  processes  proposed  are  followed  throughout  acquisition  regardless  of  if 
they  were  tailored  or  not 

•  Assemble  teams  that  have  experienced  and  SE  knowledgeable  personnel  as  a 
“non-negotiable” 

•  Ensure  processes  proposed  are  followed  throughout  acquisition,  regardless  of  if 
they  were  tailored  or  not 

•  Provide  strong  SE  leadership  on  the  team 
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II.  SASSA:  ORIGINS  AND  OVERVIEW  OF  THE  SASSA 

PROGRAM 

A.  INTRODUCTION 

Space  capabilities  are  intrinsically  woven  into  Americans’  lives,  both  civilian  and 
military.  These  include  communication  (e.g.,  DirecTV,  XM  Radio,  global  cell  phone 
nets,  global  relay  of  communication/information),  navigation,  weather,  environmental 
monitoring  and  earth  science,  and  military/national  missions  (including  ISR,  missile 
warning,  battle  space  awareness,  and  intelligence,  just  to  name  a  few).  We  are  highly 
reliant  on  our  space  assets  as  a  nation.  The  2006  U.S.  National  Space  Policy  underscores 
this  by  stating  that  “space  is  a  vital  national  interest.”  The  populating  of  space  with  U.S. 
technologies,  and  the  application  of  those  technologies,  is  essential  for  the  prosperity  of 
the  U.S.  and  global  economies.  It  links  the  globe  and  speeds  the  flow  of  information.  It  is 
becoming  a  growing  critical  aspect  of  many  areas  of  our  way  of  life  and  government. 
This  will  result  in  an  increased  stake  in  protecting  our  national  security  interests, 
intelligence,  military  uses,  and  conduct  of  U.S.  diplomacy — ultimately  to  protecting  lives 
and  the  environment. 

This  same  space  infrastructure  is  fragile.  Space  systems  are  increasingly 
vulnerable  to  a  variety  of  natural  and  man-made  threats:  space  weather  and  debris;  radio 
frequency  jamming;  laser  dazzling  and  blinding;  kinetic  intercept  vehicles;  and  space 
mines  are  just  a  few  examples.  The  U.S.  has  no  robust  Space  Situational  Awareness 
(SSA)  capability  to  unambiguously  distinguish  between  an  attack  on  a  satellite  or  a 
naturally  caused  anomaly,  especially  “in  situ.”  The  Commission  to  Assess  National 
Security  Space  Management  and  Organization  summarizes  the  theme  with  this  statement: 

If  the  U.S.  is  to  avoid  a  “Space  Pearl  Harbor”  it  needs  to  take  seriously  the 
possibility  of  an  attack  on  U.S.  space  systems.  The  nation’s  leaders  must 
assure  that  the  vulnerability  of  the  United  States  is  reduced  and  that  the 
consequences  of  a  surprise  attack  on  U.S.  space  assets  are  limited  in  their 
effects.  (2001,  January  11) 
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Various  discussion  and  documents  support  this  growing  emphasis  on  the 
criticality  of  the  SSA  of  our  space  assets.  “Counterspace  operations  have  defensive  and 
offensive  elements,  both  of  which  depend  on  robust  space  situation  awareness.”  (Gen 
John  T.  Jumper,  Foreword  to  AFDD2-2.1,  Counterspace  Operations).  The 
USSTRATCOM  JCD  for  Space  Control  (28  Jul  06)  states: 

SSA  must  enable  timely  and  accurate  resolution  between  attacks  and 
anomalies  affecting  US  capabilities,  [and]... monitor,  characterize,  predict, 
and  report  on  the  space  related  environment... detect,  process,  and  report 
space  events.... characterize,  assess,  and  resolve  anomalies/attacks  on  all 
space  systems. 

The  Space  System  Attack  ID  &  Characterization  Capability  MNS  (27  Jun  00)  relates 
needed  capabilities  by  listing  “2.a.(l)  “Detect  and  report  attacks  on  space  systems”; 
2. a. (2)  “Identify  and  characterize  attacking  systems”;  2. a. (4)  “Capabilities  must  be  rapid, 
accurate,  reliable  and  interoperable” 

Our  nation,  moving  rapidly  forward  in  technological  maturity  must  take  time  to 
address  the  combination  of  a  growing  reliance  on  space  assets  with  the  increasing 
vulnerability  of  those  same  assets.  The  Self-Awareness  Space  Situational  Awareness 
(SASSA)  program  is  one  of  a  handful  of  Air  Force  space  acquisitions  programs  that  was 
created  to  start  addressing  these  issues  moving  into  the  future. 

B.  THE  SASSA  TECHNOLOGY  DEMONSTRATOR  DESCRIPTION 
1.  Acquisition  Strategy 

The  Space  and  Missile  Systems  Center  (SMC)  requires  all  programs  to  have  an 
approved  acquisition  strategy.  The  approval  process  starts  at  the  smallest  program  office 
element  in  the  Squadron  and  filters  up  through  the  Group,  Wing,  and  then  Center 
approval  chain  processes  (if  the  program  is  large  enough).  SASSA  received  its 
acquisition  strategy  approval  on  June  2008  and  was  required  to  get  Center  level  approval. 

In  preparation  for  this  milestone  event,  the  SASSA  program  office  initiated  a 
series  of  activities  including: 
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•  Call  for  white  papers  for  possible  threat  warning  instruments 

•  SMC  survey  of  available  satellite  secondary  payload  volume,  mass,  and  power 

•  Survey  of  possible  host  vehicles  in  progress  and  their  relative  timelines  for 
development 

•  Review  of  available  satellite  bus  user  guides 

•  Review  of  industry  standard  electrical  data  bus  utilization 

•  Review  of  possible  acquisition  methods  with  pros  and  cons  (e.g.,  Sole  Source, 
Full  and  Open  competition,  University  or  UART) 

•  Financial  and  budget  analysis 

•  Industry  Day  Briefing  with  individual  company  Q&A  sessions  for  feedback 

The  synthesis  of  these  activities  led  to  a  decision  to  pursue  a  full  and  open 
competition  to  develop  space-qualified  hardware  for  a  one-year  on-orbit  demonstration. 
This  included  releasing  an  RFP  and  completing  a  source  selection.  Due  to  overwhelming 
industry  feedback,  the  program  office  seized  a  unique  opportunity  and  chose  to  award 
two  contracts  (Cost  Plus  Fixed  Fee)  out  of  the  source  selection  instead  of  a  single  award. 
These  two  contract  awards  were  envisioned  to  be  in  competition  for  the  entire  24-month 
period  of  perfonnance  towards  a  final  selection  at  flight  hardware  delivery.  The  winner  of 
the  competition  was  to  be  awarded  the  opportunity  for  integration  onto  a  host  satellite 
with  an  activation  of  an  option  for  one  year  of  on  orbit  operation  to  perform  technology 
demonstrations  with  the  selected  hardware.  To  select  the  winner  a  Flight  Selection  Plan 
was  developed  which  weighed  various  criteria  including  overall  performance,  cost, 
schedule,  and  verification  against  the  program’s  Technical  Requirements  Document 
(TRD). 
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2. 


Timeline  and  Milestones 


Figure  1  depicts  the  relative  durations  of  the  SASSA  technology  demonstration, 
rapid  space  acquisition. 
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3.  System  Description  Overview 
a.  System  Description 

The  SASSA  technology  demonstrator  will  consist  of  space,  ground  and 
test  segments.  The  SASSA  program  leveraged  mature  and  proven  technologies  and 
subsystems  to  demonstrate  a  viable  threat  warning  architecture.  It  was  designed  to  be 
minimally  intrusive  to  the  hosting  satellite  system  (both  space  and  ground  segments.)  The 
SASSA  technology  demonstrator  space  segment  is  designed  to  operate  in  low  earth  orbits 
(LEO)  between  400  km  and  1200  km. 
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b.  Space  Segment 

The  SASSA  space  segment  consists  of  the  common  interface  unit  (CIU), 
two  instruments — a  radar  warning  receiver  (RWR)  and  an  independent  dedicated  satellite 
communication  capability  (DSC),  an  MCU-110  encryption/decryption  device,  the 
mounting  structure,  and  all  associated  cabling/harness  and  software  necessary  to  operate 
the  SASSA  payload.  The  CIU  will  provide  the  ability  to  support  integration  on  heritage 
and  new  development  spacecraft  and  facilitate  integration  of  a  wide  range  of  threat 
warning  instruments  by  providing  a  variety  of  current  data  interfaces.  These  include 
1553,  SpaceWire,  or  RS-422  for  the  host  satellite  interface  and  the  same  plus  a  compact 
preconfigured  interface  (cPCI)  type  for  custom  interfaces.  The  CIU  also  provides  a  single 
electrical  power  interface  to  the  host  vehicle,  provides  power  distribution  and  control  of 
instrument  power,  fault  management,  time  &  position  services,  data  handling  &  control, 
and  on-board  data  storage. 

During  mission  operations,  encrypted  commands  are  received  over  one  of 
two  possible  communications  paths.  The  first  path  is  via  the  host  space  vehicle  interface. 
The  second  is  via  the  dedicated  stand-alone  communications  (DSC)  instrument.  Timed 
commands  are  decrypted  and  authenticated  prior  to  executing  the  commands  in  the  CIU. 
Mission  data  received  from  the  instruments  is  fonnatted  by  the  CIU  into  telemetry  frames 
and  encrypted  prior  to  sending  data  back  via  either  communication  path.  The  CIU  uses 
the  MCU-110  encryptor  to  perfonn  the  telemetry  stream  encryption  and  command 
decryption  from  the  host  satellite  data  bus  and  NSA  approved  SGLS  transponder  for  the 
DSC.  Since  the  CIU  is  handling  both  encrypted  and  plain  text  data,  the  CIU  has  a 
security  partition  to  maintain  security  isolation.  One  side  of  the  CIU  is  responsible  for 
interfacing  to  the  host  space  vehicle  and  the  other  is  responsible  for  interfacing  to  the 
instruments. 

The  instruments  receive  power,  configuration  commands,  mission  data 
files,  timing,  and  ephemeris  knowledge  from  the  CIU.  The  instruments  send  health  and 
status  telemetry  and  mission  data  to  the  CIU.  The  health  and  status  telemetry  includes 
data  collected  by  the  CIU  for  analog  temperature  monitors,  analog  voltage  monitors,  and 
digital  status  telemetry. 
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The  SASSA  Space  Segment  mounts  mechanically  to  the  host  satellite 
structure  and  receives  thermal  control,  power,  timing,  position/velocity/ephemeris  data, 
and  passes  encrypted  command  files  sent  from  the  SASSA  ground.  In  return,  the  SASSA 
space  segment  provides  the  host  space  vehicle  unencrypted  telemetry  of  digital  data 
collected  by  the  CIU  for  analog  temperature,  voltage,  and  current  monitors  as  well  as 
encrypted  mission  data/  telemetry  files. 

c.  Ground  Segment 

The  SASSA  ground  segment  provides  command  and  control,  mission 
planning,  and  processing/displaying  of  SASSA  space  segment  information.  This  includes 
mission  data  analysis  and  display,  archiving  and  trending,  threat  reporting,  and  aiding  in 
anomaly  resolution.  The  ground  segment  also  can  provide  processed  SASSA  instrument 
data  to  external  users  by  using  the  HTTP  protocol  and  posting  XML  formatted  data.  The 
ground  segment  can  interface  to  or  reside  inside  the  host  satellite  ground  station.  In  either 
location,  the  SASSA  ground  segment  can  send  and  receive  information  from  both  the 
host  satellite  communication  path  or  directly  via  the  AFSCN  network  and  the  SASSA 
DSC  instrument. 

The  SASSA  ground  segment  consists  of  three  subsystems.  The  Command, 
Control  and  Status  Subsystem  (CCS)  provides  the  communication  control  to  the  host 
ground  station  or  the  AFSCN  network.  The  CCS  also  provides  for  the  execution  of 
command  plans  and  the  health  and  status  display  and  alerting.  The  second  subsystem  is 
the  Mission  Planning  and  analysis  (MPA)  subsystem.  MPA  performs  the  operations 
scheduling,  SASSA  instrument  and  payload  resource  deconfliction,  and  timed  command 
and  command  plan  generation.  The  Instrument  Mission  Data  Analysis  Subsystem 
performs  the  mission  data  and  non-mission  data  packet  processing,  data  analysis, 
trending,  and  reporting.  The  Instrument  Mission  Data  Analysis  Subsystem  provides  a 
Web-based  HTTP  interface  for  either  browsing  by  SASSA  users  or  a  computer- to- 
computer  interface  using  XML  HTTP  post. 
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d. 


Testbed 


The  SASSA  Test  Bed  Segment  refers  to  the  SASSA  test  bed,  which 
provides  support  prior  to  and  after  launch.  The  SASSA  Test  Bed,  prior  to  launch, 
provides  support  to  SASSA  hardware  and  software  development  throughout  the  initial 
assembly  level,  unit  level  and  system  level  design  verification  and  acceptance  test  phases 
of  the  program.  During  this  phase,  the  SASSA  integration  test  bed  provides  a  platform 
for  both  integration  and  test  as  well  as  verification  and  validation  tasks.  End-to-end 
testing  is  perfonned  which  includes  instrument  stimulation  between  SASSA  and  a  host 
spacecraft  computer  simulator.  Built  in  to  the  Test  Bed  is  the  capability  to  conduct  end- 
to-end  perfonnance  testing  of  the  integrated  SASSA  space  segment.  After  launch,  the 
Test  Bed  provides  the  capability  to  aid  with  the  anomaly  resolution  processes  of  on-orbit 
hardware.  It  may  also  be  used  for  technology  insertion  evaluation  of  new  and 
developmental  threat  warning  sensors  (instruments)  and  their  compatibility  with  the 
SASSA  system. 

4.  Program  Summary  and  Current  Status 

The  SASSA  program  received  Authority  to  Proceed  (ATP)  in  October  of  2007, 
and  held  kick  off  meetings  shortly  after.  Since  ATP  SASSA  has  conducted  a  Systems 
Requirements  Review  (SRR),  Integrated  Baseline  Review  (IBR),  System  Software 
Review  (SSR),  Interim  Design  Review  (IDR),  and  Critical  Design  Review  (CDR).  In 
addition,  it  has  also  conducted  an  independent  program  assessment  (IP A)  at  the 
suggestion  of  the  SMC  commander  as  well  as  a  GAO  audit.  SASSA  was  a  dual  award 
contract  and  ran  identical,  simultaneous  programs  from  ATP  through  IDR.  The  SASSA 
program  achieved  every  milestone  on  schedule  through  CDR  for  the  first  contractor.  The 
second  contractor  held  all  milestones  on  time  except  SRR,  which  was  delayed  by  one 
month.  The  second  contractor  was  terminated  prior  to  IDR  in  order  to  retain  funding 
obligations  incurred  when  commitments  were  solidified  with  the  first  host  satellite 
program. 

The  SASSA  program  currently  has  firm  relationships  with  two  separate  satellites 


program  organizations  and  plans  to  operate  two  complete  SASSA  systems.  SASSA 
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currently  is  maintaining  its  24-month  goal  of  delivering  a  complete  baseline  system 
including  flight-qualified  hardware.  The  baseline  system  is  defined  as  a  complete  space 
segment,  a  ground  segment,  a  Test  Bed,  and  one  set  of  EDU  units  of  the  CIU  and  RWR. 
The  baseline  system  defines  a  basic  flexible  capability  ready  to  be  adapted  to  specific 
program  needs.  Deliveries  planned  in  December  2010  and  January  2011  will  contain  the 
SASSA  baseline  with  specifically  configured  space  and  ground  segments  for  each  host. 
Delta  CDR  activities,  to  assess  the  maturity  of  the  specific  modifications  needed  to  fly 
with  each  host,  are  planned  to  be  held  in  the  fall  of  2010. 

Leading  up  to  the  winter  deliveries,  the  SASSA  program  has  completed 
significant  amounts  of  material  to  date.  Two  complete  EDU  space  segments  have  been 
built  with  their  respective  unit  software.  Two  complete  ground  segments  and  two 
complete  test  beds  have  also  been  completed.  The  first  CIU  flight  unit  is  close  to 
completion  and  starting  unit  test.  The  RWR  flight  unit  is  over  80%  complete.  The 
remainder  of  the  fall  will  be  spent  completing  environmental  test  and  verification  of 
system  requirements.  This  will  conclude  the  final  build  of  space  and  ground  software  and 
as  well  as  the  completion  and  test  of  host  specific  modifications  to  the  two  units. 
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III.  STANDARD  SYSTEMS  ENGINEERING  PROCESSES 

DISCUSSION 


A.  INTRODUCTION 

As  the  need  for  more  refined  systems  and  machines  pressed  the  military  over  the 
last  half  century,  the  practices  and  standards  across  many  disciplines  for  program 
management  and  engineering  for  acquiring  these  systems  have  been  captured,  defined 
and  iterated.  These  standards  at  the  industry,  DoD  and  military  branch  levels  for 
acquisitions  attempt  to  define  a  standard  roadmap  for  all  military  acquisitions  for  the 
purposes  of  producing  the  most  effective  product  at  the  most  reasonable  cost.  Refinement 
of  these  standards  over  time  and  innovation  are  critical  to  the  continued  success  and 
optimization  of  effective  systems  for  our  modem  military. 

B.  GENERAL  SYSTEMS  ENGINEERING  PROCESSES 

The  discipline  and  specialization  of  systems  engineering  has  firmly  held  one  leg 
in  the  program  management  world  and  one  in  technical  engineering.  It  has  been  an 
essential  contributor  to  effective  technical  design  process  and  to  successful  program 
management.  Like  broader  acquisition  guidance  for  specific  engineering  disciplines, 
systems  engineering  has  also  followed  the  path  of  formalizing  its  standards  and  processes 
to  allow  formal  review  and  improvement.  It  is  the  review  and  improvement  of  these 
standards  over  a  variety  of  program  types  that  truly  lends  to  the  strength  and  adequacy  of 
the  standards  by  which  our  national  assets  are  designed  and  fielded. 

Attaining  a  concisely  articulated  working  definition  for  systems  engineering  can 
prove  to  be  difficult.  Given  the  emphasis  on  standard  guidance  for  systems  engineering 
in  this  study,  an  adequate  contextual,  working  definition  of  SE  can  be  obtained  by 
referring  directly  to  the  sources  used  for  the  study.  Standard  definitions  of  systems 
engineering  are  surveyed  below  and  include: 
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DoD  5000.02:  “Systems  engineering  provides  the  integrating  technical 
processes  to  define  and  balance  system  performance,  cost,  schedule,  and 
risk  within  a  family-of-systems  and  systems-of-systems  context.”  (p.  77) 

Defense  Acquisition  Guidebook  (DAG):  “Systems  engineering  is  an 
interdisciplinary  approach  encompassing  the  entire  technical  effort  to 
evolve  and  verify  an  integrated  and  total  life  cycle  balanced  set  of  system, 
people,  and  process  solutions  that  satisfy  customer  needs.  Systems 
engineering  is  the  integrating  mechanism  across  the  technical  efforts 
related  to  the  development,  manufacturing,  verification,  deployment, 
operations,  support,  disposal  of,  and  user  training  for  systems  and  their  life 
cycle  processes.  Systems  engineering  develops  technical  information  to 
support  the  program  management  decision-making  process. ’’(Adopted  for 
DoD  and  derived  from  EIA/IS  632,  DAG  p.  159) 

INCOSE  SE  Handbook:  “Systems  engineering  is  a  perspective,  a  process, 
and  a  profession,  as  illustrated  by  these  three  representative  definitions: 

1)  Systems  engineering  is  a  discipline  that  concentrates  on  the  design  and 
application  of  the  whole  (system)  as  distinct  from  the  parts.  It  involves 
looking  at  a  problem  in  its  entirety,  taking  into  account  all  the  facets  and 
all  the  variables  and  relating  the  social  to  the  technical  aspect.  (Ramol)  2) 
Systems  engineering  is  an  iterative  process  of  top-down  synthesis, 
development,  and  operation  of  a  real-world  system  that  satisfies,  in  a  near 
optimal  manner,  the  full  range  of  requirements  for  the  system.  (Eisner2) 

3)  Systems  engineering  is  an  interdisciplinary  approach  and  means  to 
enable  the  realization  of  successful  systems.  It  focuses  on  defining 
customer  needs  and  required  functionality  early  in  the  development  cycle, 
documenting  requirements,  and  then  proceeding  with  design  synthesis  and 
system  validation  while  considering  the  complete  problem:  operations, 
cost  and  schedule,  performance,  training  and  support,  test,  manufacturing, 
and  disposal.  SE  considers  both  the  business  and  the  technical  needs  of  all 
customers  with  the  goal  of  providing  a  quality  product  that  meets  the  user 
needs.  (INCOSE3)”  (sec  2.2,  p.  7) 

Mil  STD  499B:“An  interdisciplinary  approach  encompassing  the  entire 
technical  effort  to  evolve  and  verily  an  integrated  and  life-cycle  balanced 
set  of  system  people,  product,  and  process  solutions  that  satisfy  customer 
needs.  Systems  engineering  encompasses: 

a.  the  technical  efforts  related  to  the  development,  manufacturing, 
verification,  deployment,  operations,  support,  disposal  of,  and  user 
training  for,  system  products  and  processes; 
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b.  the  definition  and  management  of  the  system  configuration; 

c.  the  translation  of  the  system  definition  into  work  breakdown  structures; 
and 

d.  development  of  information  for  management  decision  making.” 
(Appendix  A,  p.  40) 

Aerospace  Corporation  Space  Vehicle  Systems  Engineering  Handbook 
TOR:  “The  goal  of  space  vehicle  SE  is  to  ensure  that  a  desired  system  is 
designed,  built,  and  operated  so  that  the  system  accomplishes  its  mission 
in  the  most  cost-effective  manner  possible,  considering  performance,  cost, 
and  schedule  risk.”  (SV  SE  -  1.1,  p.  1)  “System  level  SE  is  a  process  used 
to  develop  requirements  and  to  integrate  the  technical  efforts  across  a 
program.”  (2.2,  p.17)  “The  essence  of  successful  system  engineering  is  to 
get  all  of  the  elements  of  a  system  integrated  and  working  properly.” 

(4.3.1.,  p.  69). 

IEEE  Std  1220-2005QSO/IEC  26702):  “The  SEP  is  a  generic  problem¬ 
solving  process  that  provides  the  mechanisms  for  identifying  and  evolving 
the  product  and  process  definitions  of  a  system.”  (here,  SEP  is  systems 
engineering  process)  (4.1,  p.  12) 

In  summary,  systems  engineering  provides  the  discipline  in  any  acquisition 
program  that  works  to  understand  clearly  the  motivating  cause  for  the  acquisitions,  and 
then  seeks  to  systematically  achieve  that  end  through  the  rigorous  and  consistent  use  of 
processes.  In  the  most  basic  sense,  SE  attempts  to  be  the  guarantee  that  what  is  wanted  is 
what  is  achieved.  Or,  as  the  SMC  primer  states,  “SE  is  first  and  foremost  responsible  for 
ensuring  that  the  ‘right  system’  is  developed  to  meet  the  customer’s  needs,”  while 
ensuring  “that  the  ultimate  system  is  ‘developed  right.’”  (chapter  1,  p.  38) 

C.  SPACE  SYSTEMS  ENGINEERING  PROCESSES 

Thus  far,  systems  engineering  has  been  addressed  only  in  conceptual  terms 
seeking  a  solid  contextual  working  definition  for  this  study.  However,  this  study  focuses 
on  a  particular  field  of  Military  and  DoD  acquisitions — that  of  space  systems  and  SE  with 
in  this  field.  The  Space  and  Missiles  System  (SMC)  Systems  Engineering  Primer  is  a 
helpful  guide  in  describing  unique  aspects  for  space  systems  and  SE  within  this  context: 


19 


A  satellite  system  is  typically  made  up  of  one  or  more  satellites  (or  space 
vehicles),  terrestrial  satellite  control,  and  maintain  elements,  and  user 
elements  that  permit  the  operational  military  forces  to  take  advantage  of 
the  capabilities  of  the  space  system.  Each  satellite  is  made  up  of  its 
elements,  typically  the  payload  (that  provides  the  basic  mission  capability 
such  as  communications,  surveillance,  navigation,  etc.)  and  the  spacecraft 
or  bus  (that  typically  supports  the  payload  by  providing  electrical  power, 
thennal  control,  and  attitude  control,  etc.).  The  payload  and  bus  are,  of 
course,  subdivided  into  lower  tier  elements  such  as  processors,  sensors, 
communications  (radios),  and  clocks  which  are  in  turn  made  up  of  parts 
(such  as  integrated  circuits,  relays,  or  roller  bearings)  and  materials  (such 
as  metallic  or  composite  structures),  all  fabricated  and  assembled  using 
various  processes.  Similarly,  a  launch  system  is  typically  made  up  of  the 
launch  vehicles  (which  provide  the  initial  boost  toward  orbit),  upper  or 
transfer  orbit  stages  (which  place  the  satellite  in  or  near  its  operational 
orbit),  ground  control  and  monitoring  systems,  and  facilities  used  for 
checking  out,  mating,  and  supporting  the  launch  vehicles,  upper  stages, 
and  satellites  prior  to  launch.  Each  launch  vehicle  may  be  made  up  of 
multiple  launch  stages.  Each  launch  stage  and  upper  stage  is  typically 
made  up  of  propulsion,  guidance  and  control,  and  environmental 
protection  elements.  The  distinction  between  launch  systems  and  satellite 
systems  is  not  always  clear  such  as  the  case  of  the  Space  Shuttle  which  is 
a  launch  system  that  can  also  perform  or  support  operations  on  orbit  or  the 
case  of  integral  upper  stages  which  are  supplied  as  part  of  the  satellite 
system  to  complete  part  or  all  of  the  transfer  orbit  function,  (p.  2) 

In  addition  to  understanding  tenninology  and  what  a  space  system  consists  of,  it  is 
also  critical  to  understand  the  unique  elements  of  designing  satellites  and  vehicles  for 
space  in  the  SE  process.  The  SMC  SE  primer  highlights  three  main  differences  1)  the 
space  environment,  2)  unattended  operation,  and  3)  the  ultimate  high  ground.  The  space 
environment  includes  making  design  accommodation  to  operate  in  total  vacuum,  extreme 
temperature  swings  and  ranges,  operating  in  and  through  highly  charged  particles,  as  well 
as  surviving  “high  vibration,  acoustic,  shock,  and  other  environments  during  launch  and 
deployment  into  the  operational  orbit.”  (p.  3). 

The  second  unique  element  is  that,  with  the  exception  of  the  space  shuttle  and 
space  station,  all  other  space  systems  operate  unmanned.  This  adds  an  additional 
complication  for  maintenance  and  problem  resolution.  As  a  result,  space  systems  take 
advantage  of  redundant  systems  or  reloadable  software,  highly  reliable  parts,  added 

margin  to  performance  and  operational  capability.  The  primer  states,  “Experience  shows 
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that  the  cost  of  these  steps  together  with  the  cost  of  space  launch  is  perhaps  ten  times  or 
more  the  cost  of  comparable  hardware  deployed  in  terrestrial  applications. ”(p.  3)  This 
extreme  premium  on  space  hardware  cost  puts  added  pressure  and  importance  on  system 
trades  “balancing  the  operational  capability  to  be  provided  with  other  factors  such  as  cost, 
reliability,  and  service  life.”  (p.  3) 

The  final  unique  aspect  of  space  is  the  concept  of  it  being  the  final  high  ground. 
Conceptually,  space  provides  the  ultimate  tactical  and  strategic  advantage  to  arrayed 
military  forces.  As  such,  it  is  expected  to  and  has  the  responsibility  of  interfacing  a 
multitude  of  platfonns.  The  SMC  primer  states: 

The  user  equipment  for  such  systems  can  become  deployed  on  a  wide 
range  of  platforms  and  therefore  rival  or  even  exceed  the  cost  of  the 
satellites  and  launch  vehicles  so  that  the  systems  engineering  task  of 
balancing  effectiveness  and  cost  can  be  still  more  demanding  and 
important,  (p.  3) 

The  key  point  in  this  summary  is  that  an  increased  emphasis  and  importance  on  wide 
system  boundaries  makes  SE  on  space  systems  a  complicated  endeavor. 

D.  SYSTEMS  ENGINEERING  GUIDANCE  CATEGORIES 

In  the  evaluation  of  standard  SE  guidance  sources,  a  distinction  can  be  made, 

which  separates  SE  guidance  into  two  broad  categories.  The  first  category  will  be  called 

SE  processes.  This  category  contains  the  day-to-day  practical  aspects  of  the  SE  process 

which  systems  engineers  do  as  a  part  of  the  SE  process  “on  the  job.”  This  contains  both 

tasks,  which  are  accomplished  in  more  or  less  a  serial  fashion  (assuming  iterations)  as 

well  as  those  SE  processes  that  occur  throughout  the  SE  process  life  cycle.  These  include 

serial  tasks  and  processes  such  as  defining  customer  needs,  requirements  analysis, 

functional  decomposition,  as  well  as  processes  like  configuration  management  and  risk 

management,  which  occur  throughout  the  SE  process.  The  second  broad  category  of  SE 

guidance  is  that  which  will  be  called  SE  technical  management  processes.  This  category 

of  processes  is  more  specific  to  military  acquisitions  and  sits  in  the  realm  between 

program  management  and  systems  engineering.  This  contains  guidance  such  as 

implementing  SE  plans  (SEM,  SEMP)  and  the  use  of  integrated  product  teams  as  an 
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organizational  structure.  DoD  5000.02,  the  DAG,  the  SV  SE  handbook,  the  SMC  SE 
primer,  and  others  all  contain  SE  guidance  for  these  types  of  technical  management 
processes.  The  SASSA  program  tailored  standard  SE  guidance  from  both  categories  in 
order  to  more  successfully  achieve  a  rapid  space  acquisition.  Table  2  enumerates  the 
broad  spectrum  of  both  categories  of  SE  guidance. 


Serial  SE  Processes  (with  iteration) 

1.  Elicit  customer  desires/  needs 

4.  Design  Synthesis 

a.  Interface  and  boundary  identification  (physical,  logical,  functional) 

a.  Create  sequential  build  &test  plan 

b.  Functionality  identification  and  functional  architecture  development 

b.  Detailed  interface  management 

c.  Concept  Refinement 

5.  Design  Implementation 

d.  System  architecture  creation  and  representation 

a.  Elardware  fabrication 

e.  Solution  exploration  and  identification 

b.  Software  Coding 

f.  Alternate  System  Concepts  and  Elements  Definition 

c.  Technical  data  generation 

g.  Design  Constraints  Definition  and  Refinement 

6.  Analysis  and  Assessment 

2.  Requirements  and  Constraints  Capture  /  Definition  Analysis 

a.  System  optimization 

a.  Performance  requirements 

b.  Statistical  analysis 

b.  Defining  effectiveness  measures 

c.  Reliability  analysis 

3.  Allocation  and  Decomposition 

d.  Missions  and  Environments 

a.  Traceability 

7.  Verification  and  Validation  of  Requirements 

b.  Functional  and  Performance  determination 

8.  Transition 

c.  Derived  requirement  generation 

9.  Operation  Process 

d.  Elardware  /  Software  allocation 

10.  Maintenance  Process 

e.  System  element  allocation 

11.  Disposal  Process 

Parallel  or  Companion  Processes  Throughout  the  SE  Process 

1.  Configuration  Management 

6.  Trade  Studies 

2.  Quality  and  Mission  success  management 

7.  Modeling/ Simulation 

3.  Requirements  Management 

8.  SE  tools  /  strategies  application  (i.e.  Func 
Block  Diag,  Black  Box,  Func  Flow  Diag  ) 

4.  Risk  Management  and  analysis 

9.  Weighted  decision  making  processes 

5.  Specialty  Engineering  utilization  and  management 

SE  Technical  Management  Processes 

1.  Use  of  SEM/SEMP/SEMS/SEDS  plans 

7.  Use  of  KPP/KPA  and  TPM's 

2.  Organizational  Structure  -  IPT  utilization 

8.  Modular  Open  Systems  Approaches 

4.  Techncial  /  Capability  Reviews 

9.  Long  Term  Data  Managemetn  strategies 

5.  SE  Leads  and  Leadership 

10  .  Technical  /  Program  Planning  (use  of  WBS, 
IMS,  IMP,  EVMS) 

6.  Use  of  Competition 

11.  Program  Protection  and  System  Assurance 

Table  2.  Systems  Engineering  Processes  for  Acquisitions 
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E. 


BODY  OF  AUTHORITATIVE  SOURCES  FOR  SYSTEMS 
ENGINEERING 


This  thesis  sets  out  to,  first,  highlight  a  tailoring  from  accepted  standard  systems 
engineering  processes  and,  second,  to  assess  the  relative  merit  and  success  of  the  tailoring 
towards  the  intended  goal.  The  goal  in  this  program  is  achieving  a  rapid  acquisition  of  a 
satellite  payload.  In  order  to  achieve  the  first  objective,  a  standard  from  which  to  judge 
the  deviation  must  be  adopted  and  defined.  Since  the  field  of  systems  engineering  is 
diverse,  and  its  processes  can  be  applied  to  programs  of  all  sizes  and  objectives,  it  can  be 
difficult  to  establish  this  “baseline”  set  of  processes  from  which  to  draw  distinction.  This 
thesis  will  achieve  this  objective  by  defining  a  body  of  texts  as  relevant  authoritative 
source  material  that  are  available  to  government  and  military  organizations.  For  the 
purposes  of  this  study,  this  body  of  material  will  provide  the  objective  standard  of  SE 
processes  from  which  distinctions  will  be  drawn. 

The  set  of  material,  which  constitutes  the  relevant  authoritative  sources  for  this 
thesis,  is  found  in  Table  3. 


Industry  SE  Standards 

1 .  The  International  Council  on  Systems  Engineering  (INCOSE)  Systems  Engineering 
Handbook,  v.  3.2,  INCOSE-TP-2003 -002-03. 2,  Jan 2010 

2.  ANSI/GEIA  EIA-632,  Processes  for  Engineering  a  System,  01  Sept  2003 

3.  EIA/IS  731.1,  Systems  Engineering  Capability  Model,  Electronic  Industries  Alliance  (Interim 
Standard),  01  Aug  2002 

4.  IEEE  1220-2005,  IEEE  Standard  for  Application  and  Management  of  the  Systems 
Engineering  Process,  Institute  of  Electrical  and  Electronics  Engineers,  09  Sept  2005 

5.  ISCMEC  197602003  -  A  Guide  for  the  Application  of  ISO/IEC  15288 

DoD  Acquisition  Standards  (with  SE  direction) 

6.  Defense  Acquisition  Guidebook  (DAG)  Feb  19  2010,  chapter  4 

7.  Department  of  Defense  DIRECTIVE  NUMBER  5000.01  Nov  20  2007 

8.  Department  ofDefense  INSTRUCTION  NUMBER  5000.02  Dec  8  2008,  Enclosure  12 

9.  Military  Standard  499B  May  6  1994 

Space  Acquisitions  SE  Standards 

10.  The  Aerospace  Corporation  TOR-2006(8506)-4494,  Space  Vehicle  Systems  Engineering 
Handbook  3 1  Jan  2006 

1 1 .  The  SMC  Systems  Engineering  Primer  &  Handbook,  3'd  Ed,  29  Apr  2005 


Table  3.  Systems  Engineering  Guidance  Sources 


23 


This  set  of  sources  was  chosen  for  its  ability  to  cover  a  broad  range  of  application, 
for  its  ability  to  represent  the  view  of  the  only  professional  SE  accrediting  organization, 
and  for  its  ability  to  apply  directly  to  the  specific  field  of  space  acquisitions  (including 
guidance  from  the  center  in  which  the  SASSA  acquisition  was  performed  in,  SMC). 


Industry  SE  Standards 

•IEEE  Std  1220-2005  (ISO/lEC  267002)  •  INC05E-TP-2003-002-03.2 

•IEEE  Std  15288-2008  (ISO/lEC  15288)  •  ANSI/EIA-632-1999 

•EIA-  731.1 


1-5E  5ubsection 
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Figure  2.  Relationship  of  Systems  Engineering  Guidance  Sources 


F.  SUMMARY 

The  importance  of  standard  guidelines  for  DoD  acquisitions  cannot  be  understated 
for  maintaining  efficient  acquisition  while  producing  quality  products.  A  major 
undergirding  of  this  guidance  is  the  discipline  of  systems  engineering.  It  is  essential  to 
maintaining  our  present  military  capability  to  produce  acquisitions  that  replace, 
supplement,  and  advance  our  technological  capability  in  securing  and  defending  the 
freedoms  this  nation  has.  The  process  of  applying  these  standards,  tailoring  them  for 
varying  acquisition  needs,  evaluating  the  results,  and  then  capturing  them  to  pass  on  to 
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future  programs,  is  an  essential  aspect  to  keeping  our  guidance  up  to  date  and  relevant  as 
acquisition  philosophy  changes  over  time.  This  chapter  has  created  a  context  from  which 
to  evaluate  the  specific  discipline  of  systems  engineering.  Specifically  it  has  introduced 
the  unique  aspects  of  systems  engineering  for  space  systems.  It  has  defined  a  reference 
set  of  material  that  defines  standard  SE  practices  for  the  purpose  of  this  study.  This  in 
turn  allows  an  evaluation  of  specific  tailoring  implementations. 
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IV.  DISCUSSION  AND  ANALYSIS  OF  APPLICABLE  STANDARD 
SYSTEMS  ENGINEERING  PROCESSES 


A.  INTRODUCTION 

1.  SASSA  Motivation  for  Tailoring  Standard  Systems  Engineering 
Processes 

The  SASSA  government  program  office  accepted  a  difficult  challenge  upon 
contract  award  on  October  of  2008:  deliver  hardware  ready  for  a  space  flight 
demonstration  in  24  months.  By  comparison,  it  is  typical  to  expect  major  acquisitions  to 
range  over  three  to  seven  years  for  complete  space  and  ground  systems.  Smaller  unit 
development  or  technology  maturation  projects  often  take  at  least  18  months  and  often 
are  24-36  months  for  flight  ready  hardware  and  software.  In  a  surprising  contrast,  the 
SASSA  program  set  out  to  deliver  two  complete  systems,  space  and  ground,  in  24 
months. 

It  was  this  challenging  development  timeline  that  drove  the  SASSA  team  to 
seriously  challenge  the  status  quo  of  SE  practices  and  seek  optimization.  For  the  elements 
the  program  office  had  the  ability  to  change,  the  SASSA  team  adopted  a  key  paradigm: 
Executing  standard  process  in  a  manner  that  is  typically  done  on  larger/longer  space 
acquisition  programs  was  not  going  to  achieve  success  for  the  SASSA  program.  This 
paradigm  manifested  in  a  variety  of  ways  including  process  optimization  while 
maintaining  SE  discipline  and  rigor;  focusing  on  substance  and  not  simply 
process/format;  executing  processes  that  add  value  in  the  context  of  program  objectives; 
relying  upon  the  expertise  of  program  individuals,  as  opposed  to  process;  and  looking  for 
ways  to  efficiently  execute/tailor  SE  processes.  Therefore,  it  was  incumbent  on  the 
SASSA  program  to  determine  the  best  changes  in  the  execution  of  the  program  office  and 
systems  engineering  elements.  This  fundamental  view  of  space  acquisitions,  adopted  by 
the  SASSA  program  office  team,  was  the  cornerstone  for  modifying  standard  SE 
guidance. 
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2.  Guidance  for  Tailoring  from  Standard  Systems  Engineering  Sources 

Most,  if  not  all,  of  the  authoritative  SE  sources  address  the  topic  of  tailoring. 
Presumably,  this  tailoring  is  meant  to  keep  the  guidance  being  presented  usable  across  a 
variety  of  types  and  sizes  of  programs.  System  engineers  and  program  managers  are 
called  to  constantly  evaluate,  modify,  and  adapt  guidance  to  accomplish  the  overall 
goal — that  of  delivering  the  best  system  for  the  requirements  on  schedule  and  on  cost. 

Considering  the  source  material  directly  aides  in  understanding  the  full  intent  for 
tailoring  standard  SE  guidance.  Chapter  8  of  the  INCOSE  SE  handbook  states, 
“Oppressive  overhead,  with  no  visible  value  added  contributions,  is  demoralizing,  and 
may  result  in  a  system  that  costs  more  than  it  is  worth.”  (p.  301).  INCOSE  also  provides  a 
notional  (by  their  description)  diagram  aimed  at  visualizing  the  balance  between  too 
much  and  too  little  fonnality  in  SE.  This  formality  refers  here  to  the  rigid  application  of 
standard  guidance  versus  adapting  guidance  to  different  programs.  Figure  3  displays 
Figure  8-1  from  the  INCOSE  SE  Handbook.  The  handbook  goes  on  to  explain  saying: 

The  principle  behind  tailoring  is  to  establish  an  acceptable  amount  of 
process  overhead  committed  to  activities  not  otherwise  directly  related  to 
the  creation  of  the  system.  Tailoring  scales  the  rigorous  application  of  SE 
processes  to  an  appropriate  level  based  on  need  and  the  system  life-cycle 
stage,  (p.  301). 

The  Aerospace  Corporations  SV  SE  Handbook  states  similar  content  about  how 
the  SE  processes  “must  be  tailored  to  each  specific  program  to  reflect  the  scope, 
requirements,  complexity,  and  phase  of  the  program.  Tailoring  will  define  the  scope  of 
the  SE  process  and  the  effort  to  be  expended.”  (SV  SE,  p.  20).  DoD  instruction  5000.01 
sec  4.3.1.  defines  tailoring  in  its  description  of  “flexibility”  with 

There  is  no  one  best  way  to  structure  an  acquisition  program  to 
accomplish  the  objective  of  the  Defense  Acquisition  System.  MDAs  and 
PMs  shall  tailor  program  strategies  and  oversight,  including 
documentation  of  program  information,  acquisition  phases,  the  timing  and 
scope  of  decision  reviews,  and  decision  levels,  to  fit  the  particular 
conditions  of  that  program,  consistent  with  applicable  laws  and  regulations 
and  the  time-sensitivity  of  the  capability  need.  (p.  3) 
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Degree  of  formal  systems  engineering  process  used  on  the  project 


Figure  3.  Tailoring  SE  Processes  (INCOSE  SE  Handbook  Figure  8-1) 


It  expands  the  thought  in  sec  4.3.3.  with  the  description  of  “innovation”  by 

saying: 


Throughout  the  Department  of  Defense,  acquisition  professionals  shall 
continuously  develop  and  implement  initiatives  to  streamline  and  improve 
the  Defense  Acquisition  System.  MDAs  and  PMs  shall  examine  and,  as 
appropriate,  adopt  innovative  practices  (including  best  commercial 
practices  and  electronic  business  solutions)  that  reduce  cycle  time  and 
cost,  and  encourage  teamwork,  (p.  3) 

The  DAG  corroborates  by  saying, 

Although  the  system  is  based  on  centralized  policies  and  principles,  it 
allows  for  decentralized  and  streamlined  execution  of  acquisition 
activities.  This  approach  provides  flexibility  and  encourages  innovation, 
while  maintaining  strict  emphasis  on  discipline  and  accountability,  (p.  6) 

These  authoritative  sources  discuss  the  importance  and  necessity  of  tailoring  SE 
processes  for  specific  program  with  strong,  philosophical  statements.  However,  none  of 
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Formal  systems  engineering  process  followed 


the  guidance  provides  direction  for  practical  implementation  with  criteria  to  use  for 
tailoring.  This  leaves  the  SE  community  to  rely  on  experience  and  judgment  in 
determining  the  best  way  to  tailor  the  standards. 

3.  Standard  Systems  Engineering  Processes  Chosen  for  Tailoring  on 
SASSA 

Upon  the  completion  of  source  selection,  the  SASSA  government  team  took  time 
to  reflect  upon  how  best  to  execute  the  SASSA  program.  In  this  discussion  various 
aspects  of  conventional  program  management  and  SE  were  highlighted  and  decisions 
were  made  as  to  how  to  best  balance  the  needed  SE  rigor  needed  while  enabling  a  rapid 
space  acquisition.  In  a  series  of  meetings  it  was  decided  which  SE  processes  would  be 
followed,  which  tailored,  and  which  were  not  feasible  to  implement  due  to  the  program 
cost,  timeline,  resources  or  nature  of  the  24-month  technology  development  program. 

Of  the  larger  set  of  processes  listed  in  Table  2  in  Chapter  III  D,  six  were  chosen  to 
be  tailored  for  the  SASSA  program.  Two  of  these  six  are  SE  processes  and  four  are  SE 
technical  management  processes  (per  the  discussion  in  section  III  D).  These  processes 
were  perceived  at  the  time  as  being  good  candidates  for  tailoring  to  enable  more  efficient 
processes  in  achieving  the  SASSA  rapid  space  acquisition.  Table  4  lists  these  six 
processes,  which  were  tailored  for  SASSA.  Tables  5-7  list  the  standard  SE  processes 
from  the  authoritative  SE  guidance  sources  and  identify  how  the  SASSA  program 
approached  each  process  in  following  it,  modifying  it,  or  not  implementing  it.  Chapter  V 
assesses  the  tailoring  for  each  of  these  six  processes  as  implemented  in  the  SASSA 
program  for  effectiveness  in  executing  a  rapid  space  acquisition. 
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SASSA  Tailored  SE  Processes 

SASSA  Tailored  SE  Technical  Management  Guidance 

1 .  Requirements  Development 

3.  Standard  SE  Plans 

2.  Functional  Architecture  &  Design  Synthesis 

4.  SE  Leads 

5.  Technical  Reviews 

6.  IPT  Team  Structures 

Table  4.  The  SASSA  Tailored  Standard  Systems  Engineering  Processes 


1 

|  Parallel  or  Companion  Processes  Throughout  SE  | 

SASSA 

Implementation 

SASSA 

Implementation 

I 

1 .  Configuration  Management 

#1 

6.  Trade  Studies 

I 

2.  Quality  and  Mission  success  management 

I 

7.  Modeling  /  Simulation 

#i 

3.  Requirements  Management 

#1,2 

8.  SE  tools  /  strategies  application  (ie.  Func 
Block  Diag,  Black  Box,  Func  Flow  Diag ) 

I 

4.  Risk  Management  and  analysis 

X 

9.  Weighted  decision  making  processes 

X 

5.  Specialty  Engineering  utilization  and  management 

|  #  -  SASSA  Tailored  Process  ;  I  -  Implemented  Standard  Process  ;  X  -  Utilized  Development  Contractor's  Process  j 

Table  5.  Systems  Engineering  Parallel  Processes  as  Implemented  in  the  SASSA  Program 


1 

|  Serial  SE  Processes  (with  iteration)  [ 

SASSA 

Implementation 

SASSA 

Implementation 

#i 

1 .  Elicit  customer  desires/  needs 

#2 

4.  Design  Synthesis 

a.  Interface  and  boundary  identification  (physical,  logical,  functional) 

a.  Create  sequential  build  &  test  plan 

b.  Functionality  identification  and  functional  architecture  development 

b.  Detailed  interface  management 

c.  Concept  Refinement 

I 

5.  Design  Implementation 

d.  System  architecture  creation  and  representation 

a.  Hardware  fabrication 

e.  Solution  exploration  and  identification 

b.  Software  Coding 

fi  Alternate  System  Concepts  and  Elements  Definition 

c.  Technical  data  generation 

g.  Design  Constraints  Definition  and  Refinement 

I 

6.  Analysis  and  Assessment 

#  1 

2.  Requirements  and  Constraints  Capture  /  Definition  Analysis 

a.  System  optimization 

a.  Performance  Requirements 

b.  Statistical  analysis 

b.  Defining  effectiveness  measures 

c.  Reliability  analysis 

#2 

3.  Allocation  and  Decomposition 

d.  Missions  and  Environments 

a.  Traceability 

I 

7.  Verification  and  Validation  of  Requirements 

b.  Functional  and  Performance  determination 

X 

8.  Transition 

c.  Derived  requirement  generation 

X 

9.  Operation  Process 

d.  Hardware  /  Software  allocation 

X 

10.  Maintenance  Process 

e.  System  element  allocation 

X 

1 1 .  Disposal  Process 

|  #  -  SASSA  Tailored  Process  ;  I  -  Implemented  Standard  Process  ;  X  -  Utilized  Development  Contractor's  Process  j 

Table  6.  Systems  Engineering  Serial  Processes  as  Implemented  in  the  SASSA  Program 


|  SE  Technical  Management  Processes  | 

SASSA 

Implementation 

SASSA 

Implementation 

#3 

1.  Use  of  SEM/SEMP/SEMS/SEDS  plans 

#  i 

7.  Use  of  KPP/KPA/  TPM 

#6 

2.  Organizational  Structure  -  IPT  utilization 

I 

8.  Modular  Open  Systems  Approaches 

#5 

4.  Techncial  /  Capability  Reviews 

I 

9.  Long  Term  Data  Managemetn  strategies 

#4 

5.  SE  leads  and  Leadership 

I 

10  .  Technical  /  Program  Planning  (use  of  WBS, 
IMS,  IMP,  EVMS) 

I 

6.  Use  of  Competition 

I 

1 1 .  Program  Protection  and  System  Assurance 

|  #  -  SASSA  Tailored  Process  ;  I  -  Implemented  Standard  Process  ;  X  -  Utilized  Development  Contractor's  Process  j 

Table  7.  SE  Technical  Management  Processes  as  Implemented  in  the  SASSA  Program 
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B. 


SASSA  TAILORED  STANDARD  SYSTEMS  ENGINEERING  PROCESSES 


The  following  sections  describe  where  the  SASSA  program  applied  tailoring  and 
modification  in  six  specific  system  engineering  process  examples.  Each  section  includes 
a  discussion  presenting  the  standard  guidance  as  supported  by  the  authoritative  sources. 
This  is  followed  by  an  explanation  of  what  the  SASSA  program  did  to  modify  the 
standard  guidance  and  what  was  actually  implemented.  Each  section  ends  with  a 
comparing  and  contrasting  of  the  standard  SE  guidance,  versus  the  tailored  implemented 
process.  The  relative  success  of  each  tailored  process  is  addressed  in  Chapter  V,  Section 
B. 


1.  Requirements  Development 

a.  Description  of  Standard  Requirements  Development 

The  process  of  developing  requirements  is  a  fundamental  discipline  in  the 
SE  process.  As  such,  there  is  a  large  amount  of  information  available  as  SE  guidance  on 
this  subject.  The  description  here  is  not  intended  to  be  an  exhaustive  treatment  of  the 
subject,  rather  to  provide  an  adequate  summary  description  with  references  to  guidance 
documents. 

The  SMC  SE  primer  starts  describing  this  process  with  the  capabilities 
that  a  new  system  will  provide.  These  new  capabilities  will  come  from  one  of  two  paths 
(typically):  either  technology  “push”  or  capability  or  operational  “pull.”  The  “push”  case 
involves  a  technology  which  has  been  developed  and  which  is  deemed  useful  by  a 
stakeholder.  The  technology  is  judged  worthwhile  to  pursue  in  greater  development  and 
implementation  into  a  system  for  DoD  use.  For  the  “pull”  case,  there  is  a  “top-down” 
operational  desire  or  need  for  a  capability  levied.  This  need  by  the  operational  users 
needs  to  be  met,  and  thus  a  technology  development  or  acquisition  is  initiated  to  address 
the  need. 

These  “pulled”  or  “pushed”  capabilities  and  needs  subsequently  enter 
what  is  called  the  Joint  Capabilities  Integration  and  Development  System  (JCIDS) 
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process  for  the  Air  Force.  This  is  a  series  of  prescribed  and  controlled  process  steps  that 
major  acquisition  programs  are  required  to  follow.  It  is  noteworthy  that  even  non-major 
programs  are  recommended  to  use  elements  of  the  JCIDS  process.  Figure  4  is  from  the 
SMC  SE  primer  (p.  7).  This  provides  a  summary  overview  of  the  JCIDS  process.  The 
following  paragraphs  summarize  each  step  to  provide  an  overview  of  the  JCIDS  process. 
Based  upon  a  tremendous  amount  of  system  engineering  effort,  each  step  in  the  process 
produces  either  a  trade  study  or  a  requirements  document.  As  will  be  described,  the  ICD, 
CDD,  and  CPD  are  requirements  documents  with  increased  levels  of  system  specificity. 


Materiel 


Required 

Figure  3.  Key  steps  in  the  JCIDS  process 

Figure  4.  JCIDS  Process  Overview  (SMC  SE  Primer,  p.  7) 


The  first  step  is  a  Doctrine,  Organization,  Training,  Materiel,  Leadership, 
Personnel,  and  Facilities  (DOTMLPF)  capabilities  and  deficiencies  analysis.  This 
analysis  focuses  on  detennining  if  a  change  in  user  methodology,  doctrine,  policy,  or 
some  other  non-material  means  is  sufficient  to  address  the  need.  If  an  adequate  solution 
cannot  be  determined  then  it  is  decided  that  something  needs  to  be  built  to  solve  the 
problem.  The  main  focus  in  this  phase  is  to  gate  a  decision  as  to  whether  a  material 
change  is  necessary  versus  a  process  or  non-material  solution  is  adequate. 
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The  second  step  is  to  complete  an  Analysis  of  Materiel  Approaches 
(AMA).  This  process  works  to  identify  all  the  various  means,  implementations,  and 
system  approaches  that  may  be  utilized  to  meet  the  need  or  implement  the  technology. 
For  example,  “the  AMA  might  focus  on  the  preferred  approach  between  a  space-based, 
aircraft,  or  ship-based  approach  to  provide  a  surveillance  capability  but  usually  would  not 
identify  the  specific  system  concept  to  be  developed.”  (SMC  SE  Primer,  p.  6).  It 
effectively  creates  the  set  of  feasible  options  at  a  high  level  from  which  a  group  may 
choose  to  move  forward  with  a  solution  or  investigate  critical  technologies. 

The  third  step  is  the  creation  of  the  Initial  Capabilities  Document  (ICD). 
This  is  the  formal  capturing  of  the  needs  that  are  to  be  addressed  by  the  acquisition 
activity  and  subsequent  material  products.  It  also  captures  the  rationale  for  why  a  material 
solution  was  needed,  as  investigated  in  the  DOTMLPF  analysis. 

The  next  step  is  to  perform  the  Analysis  of  Alternatives,  where  the  options 
presented  in  the  AMA  are  evaluated  and  a  recommended  approach  is  decided  upon.  This 
may  be  an  approach  involving  a  single  system  in  a  single  military  branch  or  could  be  as 
expansive  as  a  system  of  systems  relying  on  multiple  acquisition  developments  run  in 
separate  military  branches  of  the  government.  At  this  stage,  the  JCIDS  process  initiates 
its  references  to  milestones.  After  the  AoA,  is  Milestone  A.  Milestone  A  has  its  own 
rigorous  process  to  enter  and  exit,  which  can  be  found  in  a  variety  of  DoD  acquisition 
guidance  documents. 

The  Capability  Development  Document  (CDD)  is  the  next  step.  The  CDD 
captures  the  information  necessary  to  develop  a  proposed  program.  Milestone  B  follows 
the  completion  of  the  CDD.  This  CDD  builds  on  the  information  in  the  AMA,  ICD,  and 
AoA  performed  previously  in  preparation  for  Milestone  A.  At  this  stage  in  the  JCIDS 
process,  an  emphasis  is  made  to  scope  the  increment  or  capability  into  achievable  and 
affordable  portions.  The  current  paradigm,  from  the  Defense  Acquisition  University,  is 
“Evolutionary  or  Incremental  Development,”  defined  as  “a  desired  capability  is 
identified,  an  end-state  requirement  is  known,  and  that  requirement  is  met  over  time  by 
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developing  several  increments,  each  dependent  on  available  mature  technology” 
(Evolutionary  Acquisition).  The  CDD  supports  the  definition  of  these  increments  in  the 
defining  of  the  program  that  will  execute. 

The  Capability  Production  Document  (CPD)  is  the  final  step  in  the  JCIDS 
process  and  supports  Milestone  C  in  the  acquisition  path.  The  SMC  SE  Primer  describes 
the  function  of  the  CPD  with  “The  CPD  addresses  the  production  attributes  and  quantities 
specific  to  a  single  increment  of  an  acquisition  program. ”(p.  42). 

The  SMC  SE  primer  highlights  how  this  guidance  applies  for  major 
programs  and  non-major  programs  and  how  both  are  expected  to  utilize  the  various 
elements  outlined: 

The  JCIDS  process  just  described  will  usually  be  applied  to  major 
programs  (those  with  high  projected  cost  or  high-level  interest).  For  non¬ 
major  programs,  the  approach  to  defining  the  capability  needs  may  be 
somewhat  less  fonnal,  but  will  usually  include  documentation  of  the  need 
in  documents  such  as  the  ICD  and  CDD.  (p.7) 

With  an  overview  of  the  entire  JCIDS  process  in  mind,  it  is  beneficial  to 
treat  in  greater  detail  where  requirements  development  occurs  and  plays  a  key  role  in  the 
larger  framework.  Within  and  between  the  CDD  and  CPD  phases  the  development  of 
program  requirements  start  (SMC  Primer,  p.  42)  (i.e.,  the  development  of  requirements 
from  which  the  space  system  can  be  designed,  built,  tested,  and  ultimately  operated  to 
satisfy  a  mission  need).  It  is  at  this  stage  of  the  requirements  development  process  that 
the  JCIDS  acquisition  process  references  other  industry  and  DoD  standards/guidance 
sources  for  requirements  development  since  this  stage  involves  a  broader  process  to  all 
SE  rather  than  just  how  the  DoD  accomplishes  their  acquisitions. 

ANSI/EIA  632  helps  identify  the  start  of  this  broader  requirements 
development  process,  which  is  stakeholder  involvement.  ANSI/EIA  632  requirement  #4 
a)  states  “Identify  stakeholders  who  will  have  an  interest  or  stake  in  the  outcome  of  the 
project.”  (pp.  10-11).  Similarly,  Requirement  15  a)  and  b)  state  “a)  Identify  and  collect 
other  stakeholder  requirements  that  can  constrain  the  system’s  end  products,  b)  Identify 
and  collect  other  stakeholder  requirements  that  can  constrain  development,  production, 
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test,  deployment/installation,  training,  support/maintenance,  and  disposal  of  system  end 
products.”  (p.  21).  Where  ANSI/EIA  632  is  an  international  industry  SE  process,  the 
DAG  helps  corroborate  the  expectation  of  stakeholder  involvement  within  the  DoD 
JCIDS  process  direction.  The  DAG  states, 

The  program  manager  and  systems  engineer  will  work  with  the  user  to 
establish  and  refine  operational  needs,  attributes,  performance  parameters, 
and  constraints  that  flow  from  JCIDS  described  capabilities,  and  then 
ensure  that  all  relevant  requirements  and  design  considerations  are 
addressed  (DAG,  4.2.3.2.I.  p.  172) 

To  accomplish  this  stakeholder  input  and  requirements  development 
process  within  the  larger  JCIDS  framework,  DoD  SE  guidance  recommends  using  the 
DoD  Architecture  Framework  (DoDAF).  This  framework  utilizes  Key  Performance 
Parameters  (KPP)  and  Key  System  Attributes  (KSA)  concepts  for  eliciting  stakeholder 
needs  and  desires.  The  DoDAF  defines  a  common  approach  for  DoD  architecture 
description  development,  presentation,  and  integration  for  both  war  fighting  operations 
and  business  operations  and  processes  (DAG  4.2.3.2.I.  p.  199).  KPPs  and  KSAs  may  be 
policy  mandatory  requirements  pushed  down  by  the  military  chain  of  command  such  as 
“Net  Ready”  or  “Sustainment,”  or  may  be  just  the  capturing  and  articulating  of  end 
metrics,  which  help  focus  the  program  on  a  desired  outcome.  ANSI/  EIA  632  supports 
this  in  Requirement  5  f)  stating  “Identify  technical  performance  measures  that  will  be 
used  to  detennine  the  success  of  the  system,  or  portion  thereof,  and  that  will  receive 
management  focus  and  be  tracked  using  Technical  Performance  Measurement  (TPM) 
procedures.”  (p.  12).  A  more  detailed  definition  of  the  function  and  purpose  of  TPMs, 
KPPs,  and  KPAs  is  provided  in  a  note  by  ANSI/EIA  632: 

NOTE — A  TPM  program  provides  an  early  warning  of  the  adequacy  of  a 
design  in  terms  of  satisfying  selected  critical  performance  parameter 
requirements  of  a  system  end  product.  TPM  also  examines  marginal  cost 
benefit  of  performance  in  excess  of  requirements.  A  critical  performance 
parameter  is  one  that  characterizes  a  significant  total  system  qualifier.  In 
addition,  it  must  be  possible  to  project  the  evolution  of  the  parameter  as  a 
function  of  time  toward  the  desired  value  at  the  completion  of 
development.  The  projection  can  be  based  on  verification,  validation, 
planning,  or  historical  data.  (p.  12) 
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The  completion  of  this  often-lengthy  requirements  process  for  the 
government  is  the  creation  of  the  Technical  Requirements  Document  (TRD).  The  KPPs, 
KPAs  and  other  stakeholder  inputs  are  captured  in  formal  program  requirements  in  the 
TRD.  This  TRD  forms  the  system  requirements  basis  for  DoD  solicitation  for 
procurement.  Based  upon  the  TRD,  the  development  contractor  usually  creates  the 
System  Specification.  The  Technical  Requirements  Documents  (TRD)  and  the  System 
Specification  are  the  two  documents  that  capture  the  total  requirements  for  a  program 
(SMC  SE  Primer  p.  7;  SV  SE  Handbook,  p.  657).  The  system  specification  then  forms 
the  basis  for  the  System  Requirements  Review  (SRR)  where  all  parties  and  stakeholders 
concur  that  an  accurate  understanding  of  the  program  requirements  has  been  captured  in 
the  system  specification.  The  validation  of  the  System  Specification  and  thus  the  TRD  for 
a  program  should  satisfy  the  KPPs  and  KPAs  for  the  specific  increment  defined  by  the 
CDD  and  CPD.  The  measured  ability  to  satisfy  these  high-level  documents  allows  the 
next  increment  to  be  initiated  in  the  overall  JCID’s  process. 

b.  SASSA  Tailored  Requirements  Development  as  Implemented 

To  fully  understand  how  the  SASSA  program  completed  requirements 
development  the  acquisition  source  of  the  SASSA  program  should  be  considered.  The 
SASSA  program  was  initiated  by  Congress  assigning  funding  to  demonstrate  a  concept 
for  providing  Space  Situational  Awareness  (SSA)  threat  warning  capability  on  a  satellite. 
In  order  to  accomplish  this  quickly,  the  JCID’s  process  was  not  used.  At  this  stage,  there 
were  no  major  stakeholders,  only  a  defined  desire  for  an  increased  technological 
application.  Those  on  the  SASSA  team  took  their  knowledge  of  SSA  current  issues, 
previous  programs,  and  long-term  planning  roadmaps  as  inputs  to  the  shaping  of  the 
program.  The  only  input  at  the  start  of  the  program  was  the  wording  provided  in  the  Air 
Force  unfunded  request  to  Congress: 

The  recent  test  (01/11/07)  of  the  Chinese  anti-satellite  weapon  (ASAT) 
demonstrated  the  most  visible  aspects  of  the  growing  counterspace  efforts 
around  the  world  which  would  exploit  the  heavy  U.S.  dependence  on 
space  assets  and  services.  SASSA  provides  the  sensing  capability  for 
current  and  future  space  high-value  assets  to  detect  and  attribute 
interference  or  attacks.  These  capabilities  are  crucial  to  enabling  a  full 
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range  of  U.S.  responses,  from  diplomatic  to  military,  in  the  event  of 
hostile  action  against  our  spacecraft.  (FY08  Air  Force  Unfunded  Request 
Language,  Courtesy  of  SAF/USA) 

Without  formal  stakeholder  requirements,  and  short  timeline,  the  SASSA 
program  had  to  decide  how  to  generate  requirements.  The  SASSA  team  attempted  to 
focus  the  technology  demonstrator  objectives  on  key  near-term  enabling  technologies. 
Thus,  in  lieu  of  actual  stakeholder  inputs,  the  SASSA  team  generated  the  closest  it  could 
approximate  given  the  larger  SSA  picture  and  incorporating  that  into  what  could  be  done 
within  the  SASSA  rapid  space  acquisition  timeframe. 

The  next  step  in  the  SASSA  TRD  requirements-generation  process  was  to 
create  a  set  of  program  functional  objectives  (Table  8,  TRD  2008)  that  would  focus  the 
technology  demonstration  and  synthesize  all  the  data  that  the  SASSA  team  had  analyzed 
regarding  mission  needs,  operational  utility,  constraints  imposed  by  existing  and  future 
satellite  systems,  as  well  as  current  technology  state.  Following  the  creation  of  the 
program  functional  objectives,  the  government  then  created  the  technical  requirements 
document  (TRD)  for  the  SASSA  program.  The  SASSA  team  ensured  that  each  TRD 
requirement  could  be  traced  back  to  at  least  one  of  the  eight  functional  program 
objectives.  This  was  viewed  as  essential  to  show  how  the  program  developed 
progressively  from  its  core  objectives. 


Program  Functional  Objectives 

R1 

Interface  with  multiple  common  spacecraft  busses 

-  Use  standard  and  common  interfaces  (hardware,  electrical,  data) 

R2 

Accept  integration  of  multiple  dissimilar  instruments 

-  Use  standard  and  common  interfaces  (hardware,  electrical,  data) 

R3 

Use  a  modular  and  scalable  software  architecture 

R4 

Build/modify  and  integrate  multiple  high  TRL  threat  warning 
instruments 

R5 

Output  sensor  information  in  an  easily  accessible  format 

R6 

Meet  the  Minotaur  &  EELV  launch  Vehicle  families 

R7 

Build  a  test  bed  to  verify  interface  compatibility  and  functionality 
through  end-to-end  testing 

R8 

Integrate  an  independent  communication  capability 

Table  8.  SASSA  Functional  Objectives 
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The  final  phase  in  the  SASSA  requirements  development  was  the 
transition  of  the  government  TRD  requirements  into  the  contractor  system  specification 
and  sub-level  specifications.  This  was  accomplished  once  the  government  obtained  a 
SASSA  development  contractor.  The  SASSA  contractor  developed  a  draft  system 
specification  that  provided  a  working  basis  for  the  System  Requirements  Review  (SRR). 
At  this  review,  each  TRD  and  system-level  requirement  in  the  system  specification  was 
discussed  in  detail  for  understanding.  Each  requirement’s  adequateness  and 
appropriateness  was  assessed. 

In  the  requirements  development  process  of  the  SASSA  program  there 
were  a  few  conscientious  decisions  made  to  enable  greater  efficiency  in  achieving 
success  in  the  rapid  acquisition.  These  were  first,  the  use  of  a  minimal  set  of  functional 
technical  requirements  in  the  TRD  (which  defined  the  core  SASSA  capabilities  required); 
second,  the  use  of  an  Excel-based  traceability  tool;  and  third,  the  development  of  a 
SASSA  interface  control  document. 

The  SASSA  government  team  attempted  to  address  multiple  issues  in 
creating  a  minimal  functional  TRD.  The  first  was  that  the  program  simply  did  not  have 
large  amounts  of  time  to  engage  in  a  TRD  process  that  similar  or  larger  programs  in  SMC 
would  go  through.  Capturing  the  essential  elements  in  performance  and  function  in  as 
few  requirements  as  possible  was  thought  to  streamline  this  process.  A  minimum  number 
of  requirements  also  gave  SASSA  the  advantage  of  less  overall  overhead  in  dealing  with 
requirements  management.  By  SASSA  consolidating  the  number  of  requirements  down 
to  a  minimum,  it  also  enabled  the  contractor  maximum  room  for  implementation,  which 
was  a  good  best  practice  for  SE  in  problem  solving.  This  was  thought  to  enable  the 
maximum  amount  of  flexibility  in  the  implementation  of  the  system  as  well,  which  was 
in  line  with  the  overall  objectives  of  the  SASSA  system.  The  result  was  a  SASSA  TRD 
with  just  over  40  requirements  (TRD,  2008). 

Another  implementation  the  SASSA  team  utilized  was  that  of  a 
traceability  matrix  in  Microsoft  Excel.  The  SASSA  program  put  a  significant  emphasis  in 
the  SE  activity  of  requirements  decomposition,  flow-down,  and  traceability  processes. 

The  standard  software,  called  Distributed  Object  Oriented  Requirements  System 
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(DOORS)  (Babcock,  2009),  presented  hurdles  in  efficiency,  which  the  SASSA  team 
sought  to  overcome.  Namely,  these  were  portability,  user  friendliness,  and  ability  to  have 
an  end-to-end  perspective  of  the  requirements  across  the  system.  (It  must  be  noted  that 
the  SASSA  development  contractor  used  DOORS  to  perform  their  requirements 
management;  they  tended  to  utilize  the  Microsoft  Excel  product  produced  from  the 
DOORS  database  in  working  situations.) 

The  solution  for  SASSA  was  a  single  spreadsheet  using  a  combination  of 
rows  and  columns  in  hierarchical  order  to  capture  requirement  numbers  and  requirement 
text,  and  how  that  requirement  was  decomposed  and  allocated  to  subsequent 
specifications.  Figure  5  shows  an  example.  Each  government  input  document  (e.g.,  SOO, 
SOW,  TRD,  CONOP)  is  allocated  a  section  of  rows  with  a  break  between  documents. 
Each  document’s  section  lists  its  input  requirements  in  successive  rows  listing  the 
requirement  number  and  language,  as  labeled  in  columns  above  these  sections.  Following 
each  requirement  in  the  next  row  down  and  in  the  adjacent  column  was  the  decomposed 
requirements  in  the  next  set  of  documents  in  succession.  The  order  started  with 
government  input  documents,  then  the  System  Specification,  Segment  Specifications, 
Unit  Specifications  and  finally  SRSs.  Each  subsequent  column  relates  the  requirements 
created  (derived)  as  a  result  of  the  higher  parent  requirement  in  the  earlier  row  and 
column.  The  resulting  matrix,  albeit  large,  allows  a  reader  to  work  in  detail,  requirement 
by  requirement,  to  see  how  a  particular  requirement  is  being  decomposed  and  addressed 
through  lower-level  derived  requirements.  The  use  of  this  matrix  was  expanded  to 
capture  performance  values  of  certain  requirements  as  well  as  verification  information 
such  as  type  of  test,  the  location  of  the  test  in  manufacturing  and  assembly,  and  the 
expected  verification  products. 
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TRD  Requirement  Flowt 

own 

Customer  TRD 
Requirement  ID 

Customer  TRD 
Requirement  Text 

Sys  Spec 
Requirement 
ID 

Sys  Spec  Requirement  Text 

Segment  Spec 
Requirement  ID 

1010 

SASSA  shall  have  two  instruments: 
Instrument  One  is  the  Radar  Warning 
Receiver  (RWR);  Instrument  Two  is  the 
Dedicated  Stand-alone  Communication 
(DSC)  system. 

SS_21 

SASSA  shall  have  two  instruments: 
Instrument  One  is  the  Radar  Warning 
Receiver  (RWR);  Instrument  Two  is  the 
Dedicated  Stand-alone  Communication 
(DSC)  system. 

SP_1 

1020 

SASSA  shall  be  available  80%  of  the 
experimental  period  after  the  flight  system 
completes  on  orbit  checkout. 

SS_4 

The  CIU  shall  perform  Power-Up  Built 
In  Test  (PBIT). 

SS_7 

Each  powered  instrument  shall  perform 
PBIT. 

SS_8 

Each  instrument  shall  report  PBIT 
results  to  the  CIU 

SP_174 

SS_95 

The  SASSA  system  shall  be  capable  of 
withstanding  exposure  to  any 
combination  of  the  Table  3-3, 
'Transportation  and  Handling 
Environments”,  including  transportation 
by  air  and/or  over- the- road,  with  no 
degradation  in  performance. 

Figure  5.  Example  of  SASSA  Excel  Traceability  Spreadsheet 


In  its  final  form,  the  matrix  allowed  a  user  to  look  at  a  single  requirement 
and  assess  its  completeness  of  decomposition  across  the  specifications  of  the  program  to 
the  resulting  design  elements:  how  each  requirement  was  assessed  in  meeting  the 
performance  aspects  of  the  requirement,  and  how  and  where  the  requirement  was  going 
to  be  verified  in  the  testing  phase  of  the  program.  The  fact  that  the  matrix  is  in  Microsoft 
Excel  means  that  it  is  easily  manipulated  in  software  that  is  almost  universally  available 
on  all  computer  systems.  Having  the  actual  language  of  all  the  requirements  in  a  traceable 
chain,  and  having  all  the  requirements  easily  identifiable  and  filterable,  makes  the  matrix 
exceptionally  useful  and  easy  to  navigate.  This  became  a  great  asset  for  thorough  review 

and  efficiency  in  performing  rigorous  SE  on  the  program. 
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Another  unique  SASSA  program  requirements  development  activity  was 
the  development  of  the  SASSA  three-volume  set  of  interface  control  documents  called 
the  Standard  Interface  Specifications  (SIS).  These  were  developed  by  the  SASSA 
program  in  looking  forward  to  activity  beyond  the  technology  demonstration. 
Specifically  they  were  developed  with  a  goal  for  follow-on  activity  in  future 
instantiations  of  SASSA  programs  as  well  as  a  method  to  capture  lessons  learned  on  the 
SASSA  program.  The  SASSA  program  conceived  that  for  SASSA  to  be  effective  into  the 
future  that  two  items  needed  to  be  addressed.  The  first  was  that  the  variety  of  threat 
warning  instruments  needed  to  be  expanded  to  be  effective.  The  second  was  that  host 
satellite  organizations  needed  to  know  what  to  expect  if  the  SASSA  concept  was  really  to 
be  proliferated.  The  SIS  volumes  were  conceived  and  written  to  address  these  needs. 

SIS  Volume  I  is  written  for  the  instrument  provider  who  is  interested  in 
building  a  SASSA  compatible  instrument.  Recall  an  “instrument”  is  any  device  that 
enables  threat  warning.  This  was  coined  to  get  out  of  the  trap  of  thinking  that  threat 
warning  is  simply  about  having  a  sensor  or  sensors.  The  instrument  concept  includes 
threat-warning  sensors,  but  allows  for  capability  enhancers  or  force  multiplying  enabling 
technologies  to  be  included.  This  includes,  for  example,  concepts  like  a  battery  backup  in 
case  primary  bus  power  is  lost.  SIS  volume  one  was  written  to  be  a  “one-stop-shop”  for 
the  instrument  vendor  who  wanted  to  get  into  the  threat  warning  instrument  field  and 
become  a  SASSA  compatible  instrument.  SIS  volumes  II  and  III  are  written  for  the  host 
satellite  programs.  Volume  II  describes  the  interfaces  between  the  SASSA  CIU  and  the 
host  space  vehicle.  Volume  III  describes  the  interface  between  the  SASSA  ground 
segment  and  the  host  ground.  The  combined  set  was  an  attempt  at  first  exposure  to  an 
organization  that  either  was  interested  in  having  a  SASSA  system  or  had  been  directed  to 
be  compatible  with  a  SASSA  system.  Each  volume  discusses  the  pertinent  information 
each  respective  space  and  ground  system  would  need  to  understand  about  the  SASSA 
hardware,  software,  procedures,  and  planning  methodologies.  This  could  bring  the 
organization  a  considerable  way  before  interacting  with  the  SASSA  team  directly  and 
facilitate  much  more  efficient  conversation. 
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c.  Comparison  of  Standard  Systems  Engineering  Guidance  to 
SASSA 

The  first  and  most  significant  deviation  from  standard  SE  guidance  was 
that  it  did  not  participate  in  any  form  of  the  JCIDS  process.  SASSA  did  not  follow  this 
guidance  to  utilize  an  ICD  or  a  CDD  in  its  requirement  generation  process. 

The  second  major  deviation  was  the  choice  to  move  forward  without 
stakeholder  input  acquired  by  standard  (JCIDS  process)  or  other  means.  A  plausible 
argument  could  be  posited  that  SASSA  would  have  had  more  value  if  stakeholder  inputs 
from  the  Air  Force  MAJCOM  requirement  offices  and  operational  users  were  garnered 
before  moving  forward  with  any  type  of  hardware  development.  The  SASSA  team 
considered  this.  It  determined  the  process  of  gathering  this  feedback  could  easily 
consume  the  majority  of  the  24-month  timeline  for  the  effort.  Therefore,  the  SASSA  team 
chose  to  move  forward  with  a  spaceflight  demonstration  and  utilize  as  much  input  as 
could  be  obtained  in  the  process.  Ultimately,  the  majority  of  inputs  were  from  those  who 
had  worked  in  previous  organizations  of  interest  or  generated  by  the  SASSA  team. 
SASSA  decided  that  flying  a  technology  demonstrator  would  be  more  valuable  at 
eliciting  stakeholder  input  and  involvement  than  spending  the  money  entirely  on 
attempting  to  garner  support  and  stakeholder  buy-in. 

The  third  aspect  where  SASSA  deviated  from  standard  SE  guidance  was 
in  not  identifying  particular  KPPs,  KPAs,  or  TPMs  for  the  program  as  recommended.  A 
KPP/KP A/TPM  is  identified  as  attempting  to  “provide  an  early  warning  of  the  adequacy 
of  a  design  in  terms  of  satisfying  selected  critical  performance  parameter  requirements  of 
a  system  end  product.”  (ANSI/EIA  632,  p.  12).  This  function  was  not  explicitly  defined 
for  SASSA  in  the  form  of  KPP/KP  A/TPMs,  rather  SASSA  judged  each  of  the  TRD 
requirements  as  tier  one  or  tier  two  (TRD,  2008).  All  the  tier  one  requirements  were 
deemed  to  be  essential  to  the  success  of  the  SASSA  program  and  were  watched  closely 
and  specifically  assessed  at  every  major  milestone  review.  It  should  be  noted  that  the 
SASSA  program  did  regularly  status  particular  key  requirements  in  monthly  reviews  and 
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referred  to  them  as  TPMs.  Despite  having  the  same  name,  the  SASSA  TPMs  and  those 
highlighted  as  KPPs  or  KPAs  in  the  standard  SE  guidance  did  not  accomplish  the  same 
function. 

2.  Functional  Architecture  and  Design  Synthesis 

a.  Description  of  Functional  Architecture  and  Design  Synthesis 

The  functional  architecture  and  design  synthesis  process  in  SE  occurs  after 
the  requirements  definition  and  allocation  steps  have  been  completed.  The  “functional 
architecture”  here  may  refer  specifically  in  the  larger  DoD  acquisition  as  what  is 
developed  and  utilized  in  the  JCIDs  process  and  in  conjunction  with  the  AM  A  and  AO  A 
process  steps.  This  phrase  may  also  be  used  in  the  more  general  SE  process  steps  as  an 
element  of  the  SE  process  in  moving  from  specific  requirements  to  design  elements.  This 
study  is  referring  to  the  later  of  these  two  in  this  section. 

The  SMC  SE  Primer  describes  this  process  in  the  broader  context  of  the 
other  SE  processes  depicted  in  Figures  6  and  7  (pp.  44,  46). 
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Process  Input  — 

Customer  Need  s/Objectives/ Requirements 
—  Missions,  Measures  of  Effectiveness, 
Environments.  Constraints 
Technology  Base 

Output  Requirements  from  Prior  Development  Effort 
Program  Decision  Requirements 
Requirements  from  Specs  and  Stds 


Requirements  Analysis 

Analyze  Missions  and  Environments 
Identify  Functional  Requirements 
Define/Refine  Performance  and 
Design  Constraint  Requirements 


Requirements  Loop 


Verify 


Functional  Analysis/Allocation 

Decompose  to  Lower-Level  Functions 

ABocate  Performance  and  Other  Limiting 

Requirements  to  AI  Functional  Levels 

Define/Ref  ne  Functional  Interfaces  (IntemaVExtemal) 

Define/Refine/Integrate  Functional  Architecture 


J  i  Design  Loop 


Trade-Off  Studies 
Effectiveness  Analyses 
Risk  Management 
Configuration  Mgt 
Interface  Management 
Data  Management 
Performance 
Measurement 
-SEMS 
-TPM 

—  Technical  Reviews 


Synthesis 

T ransform  Architectures  (Functional  to  Physical) 

Define  Alternative  System  Concepts.  Configuration 
Items  and  System  Elements 
Select  Preferred  Product  and  Process  Solutions 
Define/Refine  Physical  Interfaces  (Intemal/Extemal)  Verify 


Related  Terms 
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Figure  6.  Simplified  SE  Process  (from  Figure  13  SMC  SE  Primer) 


Specifically,  The  SMC  Primer  provides  working  definitions  for  the 
Functional  Architecture  and  Synthesis  steps: 

The  functional  architecture  defines  how  the  functions  will  operate  together 
to  perform  the  system  mission(s).  Generally,  more  than  one  architecture 
can  satisfy  the  requirements.  Usually  each  architecture  and  its  set  of 
associated  allocated  requirements  have  different  cost,  schedule, 
performance,  and  risk  implications,  (p.  49) 

Synthesis  is  the  process  whereby  the  functional  architectures  and  their 
associated  requirements  are  translated  into  physical  architectures  and  one 
or  more  physical  sets  of  hardware,  software  and  personnel  solutions,  (p. 
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Synthesis 


Transform  Architecture 
From  Functional  to  Physical 


Define  Alternate 
System  Concepts/CIs, 
System  Elements 


Define  Alternate  Product 
and  Process  Solution 


Verification  ^  * 


Define/Refine  Internal 
and  External  Interfaces 


Process 

itm  it 

i 

Figure  7.  Requirements  Analysis  Process  (SMC  SE  Primer  Figure  14) 


These  two  steps  taken  together  result  in  the  translating  of  particular 
requirements,  represented  as  needed  functions  that  are  grouped  logically,  into  a  physical 
design.  This  is  often  the  aspect  of  design  and  engineering  that  is  most  often  looked 
forward  to  or  jumped  into  prematurely.  If  followed  rigorously  to  this  point,  ideally  the  SE 
process  will  have  avoided  preconceived  physical  implementations  of  requirements  and 
functional  allocations.  It  is  in  this  stage  where  design  is  conceived  to  meet  sets  of  needed 
functions  that  in  turn  are  then  represented  as  physical  designs.  The  implementation  of  this 
design  can  lead  to  commercial  off  the  shelf  (COTS)  usages  or  identified  needs  for 
modified,  new,  or  state-of-the-art  hardware  that  does  not  exist. 

A  related  and  essential  aspect  of  this  phase  is  the  identification  of  the 
internal  and  external  interfaces.  Up  to  this  point  in  the  SE  process,  there  will  only  have 
been  requirements  and  functions  identified.  As  these  functions  are  logically  grouped,  the 
early  identification  of  interfaces  can  take  shape.  The  internal  interfaces  may  represent 
interfaces  between  functions  within  a  particular  grouping  of  functions,  or  between  logical 
groupings  of  functions.  External  interfaces  are  those  that  are  those  at  the  boundaries  of 
the  system  and  groupings  of  functions.  As  the  SE  process  is  advanced,  these  internal  and 
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external  interfaces  take  on  specific  fonn  and  detail.  These  may  be  functional,  procedural 
or  have  physical  aspects  such  as  power,  data,  or  timing  signals.  The  goal  of  the  synthesis 
section  in  producing  an  approved  design  implementation  that  meets  the  needed  functions 
is  to  also  to  have  identified  all  the  interfaces,  internal  and  external,  and  their  respective 
detailed  information. 

During  this  functional  architecture  and  design  synthesis  phase,  it  is 
recommended  that  multiple  alternatives  be  carried  in  parallel.  These  alternatives 
represent  different  cost,  risk,  and  performance  implementations,  and  are  utilized  as  a 
method  of  risk  management.  These  various  implementations  allow  the  program  a  “back¬ 
up”  should  the  higher-perfonnance  (or  primary)  solution  prove  infeasible,  too  costly,  or 
require  too  lengthy  of  a  development  schedule  (SMC  SE  Primer,  p.  49).  As  a  design  trade 
exercise,  a  program  will  assess  all  the  alternatives  and  choose  a  primary  path  to  be 
developed.  The  other  paths  can  remain  in  a  less  mature  state  until  there  are  signs  that  they 
many  need  to  be  developed  and  implemented  as  a  risk  reduction  strategy. 

b.  SASSA  Tailored  Functional  Architecture  Design  and  Synthesis 
as  Implemented 

The  SASSA  program  made  certain  decisions  early  in  the  program 
planning  stages,  which  directly  shaped  the  functional  architecture  and  design  synthesis 
phase  for  the  contractor.  In  the  simplest  terms,  the  government  office  performed  early 
stages  of  the  functional  architecture  and  synthesis  design  process.  This  resulted  in 
requirements  for  the  potential  offerors  to  propose  to  in  the  RFP.  The  steps  that  the 
government  office  took  were  first  to  translate  the  congressional  language  into  broad 
objectives.  The  second  phase  was  to  generate  various  possible  design  implementations  by 
creating  reference  architectures.  This  process  also  served  a  secondary  purpose  in  aiding 
cost  estimation  for  program  budget  planning.  This  trade  space  of  reference  architectures 
was  generalized  into  various  potential  mechanical  hardware  implementations  and  then 
converted  back  into  a  functional  block  diagram  formats  as  an  attempt  to  encourage 
creativity  to  solve  the  problem  but  within  certain  mechanical  constraints. 
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The  process  of  generating  possible  design  implementations  and  creating 
reference  architectures  occurred  in  the  program  after  the  SASSA  program  was  notified 
that  it  was  likely  to  receive  funding.  This  task  was  conducted  internal  to  the  Air  Force 
SMC  Wing  organization,  and  in  collaboration  with  the  government  personnel  and 
contracted  support  personnel.  This  scope  of  the  short  analysis  of  alternative  type  study 
was  to  determine  the  best  and  most  useful  combinations  of  technology  demonstrations 
between  ground  and  flight  options,  and  what  aspects  of  the  system  should  be  placed  in 
priority  over  others.  It  also  set  out  to  determine  what  types  of  sensors  to  make  a  priority 
in  the  SSA  threat  warning  suite  since  it  was  likely  to  be  cost  constrained. 

This  was  useful,  first,  in  defining  the  boundaries  of  the  SASSA  system  for 
the  possible  range  of  solutions.  It  was  also  helpful  in  defining  likely  interfaces  for  the 
system.  This  sense  of  interfaces  and  solution  boundaries  helped  determining  feasible  and 
infeasible  architecture  solutions  for  consideration.  The  less  feasible  solutions  would 
likely  require  higher  levels  of  technology  maturity  or  development  risk.  The  more 
feasible  solutions  would  require  less  risk  and  could  be  developed  more  quickly.  This 
study  also  helped  identify  realistic  expectations  for  technical  capability  ranges.  This 
included  sensor  capabilities  for  various  threats,  realistic  views  of  orbit  ranges,  and  a 
better  understanding  of  the  size,  weight,  and  power  of  such  systems  in  space.  This 
combined  sense  of  what  was  possible  with  an  associated  risk  provided  useful  data  as  a 
context  for  deciding  the  best  method  of  program  execution  and  building  a  feasible  plan  in 
schedule  and  budget  for  meeting  the  rapid  space  acquisition. 

The  output  of  this  study  period  was  what  ultimately  led  to  the  modification 
of  the  design  and  synthesis  SE  process  for  the  SASSA  program.  It  was  detennined  that  in 
order  to  achieve  the  rapid  acquisition  in  the  allotted  time  aspects  of  the  design  synthesis 
and  SASSA  technology  demonstrator  needed  to  be  constrained.  The  end  result  was  a  set 
of  required  segments,  a  set  of  required  functions  specific  to  each  segment,  and  a  set  of 
required  mechanical  hardware  unit  implementations  specific  to  the  space  segment. 

A  final  aspect  of  SASSA’ s  implementation  of  the  functional  architecture 
design  and  synthesis  process  was  the  decision  to  utilize  high  heritage  and  high  technical 

readiness  level  (TRL)  hardware.  This  included  the  constraint  of  NSA  type  one  approved 
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encryption  and  decryption  capability.  All  units  had  to  have  some  heritage  relationship 
and  were  required  to  be  at  TRL  six  or  above,  or  to  have  a  government-approved  TRL 
maturity  plan  approved.  This  decision  was  made  in  an  effort  to  meet  the  rapid  24-month 
schedule  with  flight  ready  hardware  ready  for  a  space  flight  demonstration.  Overall,  this 
constraint  limited  the  total  possible  solutions,  but  allowed  for  lower  risk  designs  that  had 
a  basis  in  previous  efforts. 

c.  Comparison  of  Standard  Guidance  to  SASSA 

In  this  instance  the  difference  between  standard  SE  guidance  and  what  the 
SASSA  program  implemented  is  more  subjective  than  previous  categories.  This  has  to  do 
with  where  one  draws  the  line  between  a  legitimate  constraint  in  the  SE  development 
process  and  a  strict  interpretation  of  the  Prephase  A  concept  generation  phase.  If  a  strict 
interpretation  (or  more  purist  SE  approach)  is  taken  then  there  really  should  be  no 
constraints  on  the  system  except  those  strictly  necessary  to  address  the  needed 
capabilities  and  functions.  This  creates  an  extremely  open  trade  space,  which  encourages 
creative  problem  solving  with  innovative  solutions.  At  some  point,  legitimate  options  in 
the  trade  space  in  this  open  style  SE  approach  will  be  weeded  out  due  to  realism  being 
added  back  into  the  system.  Less  feasible  and  unrealistic  solutions  will  then  not  be 
pursued  in  the  military  acquisition — as  appealing  as  those  envisioned  capabilities  may  be. 

If  this  view  of  SE  is  adopted  and  used  to  judge  against  what  the  SASSA 
program  implemented,  it  would  have  deviated  greatly.  This  would  have  constrained  many 
aspects  of  the  possible  design  space  in  the  very  early  phases  by  interpreting  the 
congressional  language  into  reference  designs.  To  be  more  in  line  with  the  SE  guidance 
the  SASSA  program  should  have  left  the  contractor  much  more  trade  space  to  consider 
design  options  as  long  as  they  could  justify  that  they  were  meeting  the  intent  of  the 
direction  and/or  higher  level  objectives  decomposed  from  the  congressional  language. 

The  SASSA  program  could  also  be  judged  against  a  more  liberal 
interpretation  of  the  SE  guidance.  This  view  may  allow  greater  constraints  to  be  imposed 
earlier  in  the  SE  process,  thereby  constraining  the  possible  set  of  feasible  designs, 
justified  as  an  aspect  of  meeting  the  overall  goal  of  the  SE  process.  In  this  interpretation, 
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SASSA  would  not  be  judged  to  have  deviated  greatly.  SASSA  would  be  viewed 
compliant  for  having  provided  functional  requirements  and  objectives.  They  may  have 
been  judged  as  having  deviated  from  guidance  by  provided  aspects  of  the  design  by 
segment  or  even  dictating  specific  implementations  for  the  CIU,  RWR,  and  DSC 
instruments. 

3.  Standard  Systems  Engineering  Plans 

a.  Description  of  Standard  Systems  Engineering  Plans 

Standard  systems  engineering  plans  is  the  tenn  designated  in  this  study  to 
refer  to  the  family  of  similar  documents  described  in  systems  engineering  guidance, 
which  address  a  standard  description  of  how  systems  engineering  will  be  accomplished  in 
an  acquisition.  Typically  developed  in  the  early  stages  of  an  acquisition,  it  can  include  all 
of  the  following:  the  Systems  Engineering  Plan  (SEP),  the  Systems  Engineering 
Management  Plan  (SEMP),  the  Systems  Engineering  Master  Schedule  (SEMS),  and  the 
Systems  Engineering  Detailed  Schedule  (SEDS). 

MIL-STD-499B  section  4.1,  titled  “Systems  Engineering  Planning 
Implementation,”  provides  requirements  for  the  developing  of  and  implementations  of 
systems  engineering  plans  stating,  “The  integrated  technical  effort  shall  be  reflected  in 
the  Systems  Engineering  Management  Plan  (SEMP),  the  Systems  Engineering  Master 
Schedule  (SEMS),  and  the  Systems  Engineering  Detailed  Schedule  (SEDS)”  (p.  9).  It 
goes  on  to  describe  how  the  government  should  write  and  provide  the  SEMP  as 
contractual  direction  where  the  “performing  activity”  (i.e.,  the  contractor)  should  execute, 
maintain,  and  update  the  SEMP  (p.9).  It  also  describes  how  the  contractor  should  be 
tasked  to  develop  the  Systems  Engineering  Master  Schedule  (SEMS),  and  the  Systems 
Engineering  Detailed  Schedule  (SEDS). 

The  Space  Vehicle  SE  Handbook  provides  similar  direction  in  sections 
2.2. 2. 7  titled  “Government  Systems  Engineering  Plan,”  and  2. 2.2. 8.  titled  “Government 
Development  Plan.”  This  handbook  states,  “The  purpose  of  a  government  SEP  (or  its 
equivalent)  is  to  organize  government  teams’  roles,  accountabilities,  and  products.”  (p. 
29).  It  also  addressed  other  plans  by  saying  that  “...it  is  necessary  to  have  a  systems 
engineering  master  schedule  (SEMS)  or  the  equivalent”  (p.  9). 
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The  Defense  Acquisition  Guidebook  corroborates  this  direction  in  section 

4.2.2.  stating, 

Best  practice  is  to  align  the  government  SEP  with  the  contractor's 
SEP/SEMP/technical  plan  following  contract  award  and  maintain 
alignment  and  currency.  Where  practical,  these  documents  should  initiate 
a  process  to  unify  the  program  technical  planning  between  government 
and  contractor(s)  (p.  175). 

It  is  helpful  at  this  point  to  understand  the  general  topics  and  themes 
covered  in  a  SEP  and  SEMP  in  order  to  gain  a  context  for  understanding  how  SASSA’s 
tailored  SE  processes  addressed  the  same  topics  or  themes.  The  SEP  is  the  government’s 
systems  engineering  plan  while  the  SEMP  is  the  contractors  system  engineering 
management  plan. 

Appendix  Cl  of  the  SMC  SE  Primer  provides  an  example  SEP  outline.  A 
sampling  of  key  topics  is  captured  in  Table  9. 


•  Systems  Engineering  Organization 

•  Technical  Reviews 

•  Certification  Requirements 

•  Configuration  Management 

•  Configuration  Management 

•  Technical  Baseline  Management 

•  Systems  Safety 

•  Data  Management 

•  Systems  Engineering  Tools 

•  Interface  Management 

•  Verification  and  Validation 

•  SE  and  Management  Tools 

•  Security 

•  Program  Integration 

•  Specialty  Engineering 

•  Contract  Management 

•  Resource  Allocation 

•  Work  Breakdown  Structure 

Table  9.  Sample  SEP  topics 

Appendix  Cl  of  the  SMC  SE  Primer  also  provides  an  example  SEMP 
outline.  A  sampling  of  key  topics  is  captured  in  Table  10. 
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•  Systems  Engineering  Process 

•  Systems  Analysis  and  Control 

•  Requirements  Analysis 

•  Risk  Management 

•  Functional  Analysis  and  Allocation 

•  Configuration  Management 

•  Synthesis 

•  Interface  Management 

•  Technical  Performance  Measurements 

•  Data  Management 

•  Technical  Reviews  and  Audits 

•  Specifications 

•  Configuration  baselines 

•  Verification  Planning 

•  Systems  Engineering  Tools 

Table  10.  Sample  SEMP  topics 


b.  SASSA  Tailored  Systems  Engineering  Plans  as  Implemented 

The  SASSA  government  team  used  a  series  of  processes  and  tools  to 
define  and  determine  its  SE  approach  for  the  SASSA  program,  as  well  as  its  expectations 
for  the  contractors.  The  first  was  technical  meetings,  discussing  the  SE  approach  to  be 
used  for  the  government  team  and  what  should  be  required  of  the  contractor.  This 
discussion  covered  various  levels  of  formality  and  responsibility  for  boards  (e.g., 
configuration  management,  part  selection,  failure  review,  risk  management).  This 
included  discussion  of  what  various  SE  elements  on  the  program  should  be  under 
governmental  control.  It  was  consensus  from  these  discussions  that  the  SASSA  team 
moved  into  the  second  major  process,  the  preparing  of  the  RFP  for  the  source  selection. 

The  drafting  process  for  the  RFP  continued  to  align  and  solidify  the  views 
of  the  government  members  as  well  as  capture  the  consensus  in  the  source-selection 
evaluation  criteria.  Multiple  sections  of  the  evaluation  criteria  required  the  contractor  to 
provide  justification  of  their  SE  processes.  This  provided  criteria  from  which  to  judge  the 
SE  capability  and  processes  of  the  offerors  (SASSA  contractors).  It  also  solidified  the 
government  team’s  approach  and  expectations  for  the  contractor  for  SE  processes.  A 
beneficial  side  effect  was  a  configuration-controlled  (via  source-selection  process) 
assessment  of  each  contractor’s  SE  approach  and  plan.  The  government  team  had  the 
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opportunity  to  evaluate  the  potential  offeror’s  responses  to  these  process  requirements, 
and  ask  questions  of  the  contractor — to  make  sure  they  clearly  understood  the  ability  and 
intent  of  the  contractor  in  doing  SE  on  the  SASSA  program. 

The  next  tool  the  SASSA  team  used  was  the  integrated  master  schedule 
(IMS).  This  defined  for  the  program  major  SE  functional  tasks  and  phases,  as  well  as 
other  required  contractual  deliveries.  The  government  also  used  contractual  deliveries  in 
the  form  of  Contract  Data  Item  Deliverables,  known  as  CDRLs.  Examples  of  CDRLs 
chosen  to  aid  in  understanding  the  contracts  SE  process  and  plans  include  a  government- 
approved  software  development  plan  (SDP),  configuration  management  plan,  and  a  parts 
management  plan  (PMP). 

Once  the  SASSA  program  was  initiated  and  running,  the  program  utilized 
other  processes  to  augment  the  SE  process  already  captured.  The  SASSA  program  office 
utilized  a  combination  of  government-only  processes,  as  well  as  contractor-led  processes. 
The  government-led  processes  included  engineering  review  boards  (ERBs),  change 
control  boards  (CCBs),  requirement  analysis,  and  approval.  These  particular  processes 
were  chosen  by  the  government  because  they  represented  key  nodes  in  the  SE  process  at 
the  government  level.  Issues  raised  to  these  process  levels  needed  to  be  controlled  at  the 
government  level  due  to  their  potential  for  significant  shifts  in  the  program  requirements, 
design  capability,  or  overall  performance. 

The  SASSA  program  also  made  use  of  the  established  contractor  corporate 
processes  for  risk  management,  trade  studies,  configuration  management  (CM), 
requirements  allocation  and  verification,  and  failure  review  boards  (FRBs).  Additionally, 
the  contractor  proposed  the  use  of  their  command  media  SEMP  as  an  already  established 
practice.  This  benefited  the  program  without  having  to  expend  time  or  resources  in 
writing  one  for  the  SASSA  program.  These  particular  processes  were  chosen  because 
they  were  good  candidates  to  run  efficiently  at  the  contractor  level.  They  were  already  in 
contractor  “format”  and,  as  such,  were  easy  and  efficient  to  implement.  These  processes 
instilled  adequate  SE  process  checks  at  the  developer  level,  without  adding  significant 
overhead  or  resource  drain  to  the  contractor. 
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Overall,  the  SASSA  program  implemented  a  wide  variety  of  smaller,  easy- 
to-implement  processes  that  took  advantage  of  the  natural  progression  of  the  program  in 
order  to  define,  communicate,  and  execute  the  plan  for  doing  systems  engineering.  These 
processes  utilized  a  combination  of  pre-contract  award,  government-run,  and  contractor- 
run  processes,  and  represented  the  complete  SASSA  approach  for  executing  systems 
engineering  on  this  rapid  acquisition. 

c.  Comparison  of  Standard  Guidance  to  SASSA 

The  SASSA  team  did  not  follow  SE  guidance  for  creating  a  SEP,  SEMS, 
and/or  SEDS.  Rather,  the  team  adapted  a  series  of  other  tools  and  processes.  The  SASSA 
team  decided  to  try  to  keep  the  program  as  streamlined  and  efficient  as  possible, 
minimizing  the  required  overhead  to  the  bare  minimum,  while  still  achieving  the 
necessary  insight  for  implementing  SE  on  the  SASSA  program.  This  “light  and  lean” 
approach  consisted  of  a  variety  of  individual  elements  taken  as  a  whole  for  how  SE 
would  be  implemented  on  the  program. 

These  elements  consisted  of  1)  the  RFP  evaluation  criteria  for  processes 
for  systems  engineering  and  software  engineering  management — this  captured  in  a 
configuration-controlled  format — the  government’s  expectations  for  SE  implementation 
on  the  SASSA  program;  2)  the  contractor’s  proposal  response  to  the  RFP  for  these 
criteria — this  articulated  the  contractor’s  process  and  plan  without  requiring  a  standard 
SEMP  or  similar  documentation;  3)  the  integrated  master  schedule  (IMS) — this  captured 
major  SE  milestones  and  task  phases  and  their  interrelations  to  other  critical  events;  4) 
the  required  contractual  deliveries  (CDRLs)  that  are  government  approved  for  CM,  PMP, 
and  the  SDP — this  provided  governmental  influence  on  critical  detail  elements  of  SE 
implemented  on  the  program. 

The  complete  combination  of  these  elements  allowed  the  SASSA  team  to 
save  resources  and  time  for  both  the  government  team  and  contractor  teams,  while  still 
achieving  a  necessary  understanding  and  agreement  for  how  SE  would  be  implemented 
on  the  SASSA  program. 
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4. 


Use  of  Systems  Engineering  Leads 


a.  Description  of  Systems  Engineering  Leads  From  Guidance 

The  directed  use  of  systems  engineering  leads  is  discussed  primarily  in  the 
Defense  Acquisition  Guide  (DAG),  but  is  also  included  in  DoD  5000.02,  which  the  DAG 
references  and  then  expands  on.  The  major  direction  from  SE  guidance  is  to  appoint  a 
systems  engineering  lead  for  a  program.  Both  DoD  5000.02  and  the  DAG  talk  to  this 
aspect: 


Each  PEO,  or  equivalent,  shall  have  a  lead  or  chief  systems  engineer  on 
his  or  her  staff  responsible  to  the  PEO  for  the  application  of  systems 
engineering  across  the  PEO's  portfolio  of  programs.  The  PEO  lead  or  chief 
systems  engineer  shall:  a.  Review  assigned  programs'  SEPs  and  oversee 
their  implementation  b.  Assess  the  performance  of  subordinate  lead  or 
chief  systems  engineers  assigned  to  individual  programs  in  conjunction 
with  the  PEO  and  PM.  (5000.02,  p.77) 

This  technical  authority  should  ensure  not  only  proper  systems 
engineering  process  application  to  programs  but  also  to  proper  training, 
qualification  and  oversight  of  systems  engineering  personnel  assigned  to 
programs.  As  part  of  this  overall  responsibility  for  technical  oversight,  the 
technical  authority  should:  Nominate  a  lead  or  chief  systems  engineer  to 
the  program  manager  at  the  initial  stages  of  program  formulation.  The  lead 
or  chief  systems  engineer  should  be  accountable  to  the  program  manager 
for  meeting  program  objectives,  and  accountable  to  the  systems 
engineering  technical  authority  for  the  proper  application  of  systems 
engineering.  (DAG,  p.  173) 

Guidance  is  straightforward  in  its  intent  for  each  program  following  it  to 
assign  a  systems  engineering  lead  for  each  program.  It  is  then  this  individual’s 
responsibility  to  oversee  and  ensure  the  implementation  of  the  proper  application  of 
systems  engineering  for  meeting  the  program  objectives.  According  to  5000.02  and  the 
DAG,  there  should  be  an  assigned  SE  lead  for  every  program. 

b.  SASSA  Tailored  Systems  Engineering  Leads  as  Implemented 

The  SE  function  for  the  SASSA  program  was  performed  as  any  of  the 
other  tasks  that  needed  to  take  place  on  the  SASSA  program.  Chapter  IV,  B  6,  will 
discuss  this  application  in  light  of  IPT  structures  on  the  SASSA  program.  In  the  interim, 
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it  is  important  to  understand  that  there  was  no  IPT  structure  on  the  SASSA  government 
program.  SE  tasks  were  assigned/allocated  to  the  individual  best  able  to  work  the  task. 
As  a  result,  SE  for  the  program  was  done  in  a  team  fashion,  with  individual  elements 
being  worked  by  individuals  approved  and  iterated  by  the  consensus  of  the  group.  The 
results  of  the  task(s)  were  presented  to  the  larger  team  and  defacto  brought  to  consensus 
given  peer  review.  The  task  lead  acted  as  the  issue  lead,  and  the  Air  Force  officer  in 
charge  approved  the  final  product  for  the  program. 

c.  Comparison  of  Standard  Guidance  to  SASSA 

The  primary  deviation  from  standard  SE  guidance  and  the  SASSA 
program  as  implemented  was  that  SASSA  did  not  appoint  or  use  a  SE  lead  for  the 
SASSA  program.  There  was  no  single  person  assigned  the  responsibility  for  ensuing 
what  SE  processes  were  followed  or  ensuring  they  were  accomplished.  The  SASSA 
program  took  a  simplified  approach  with  a  much  flatter  organizational  structure.  This 
structure  basically  had  a  single  lead  with  a  group  of  people  without  titles,  who  all 
participated  to  make  the  SASSA  program  a  success.  Each  program  task  was  delegated  a 
lead,  which  matured  the  task  to  a  level  where  the  rest  of  the  team  could  provide  feedback. 
The  SE  for  the  program  followed  the  same  pattern.  To  date,  there  is  no  single  SE  lead  in 
charge  of  the  SE  aspect  of  the  government  team.  This  implementation  can  sound  very 
counterproductive  towards  the  goal  of  accomplishing  excellent  SE.  This  indeed  is  a  risk 
for  every  team  adopting  this  method.  However,  the  SASSA  team  considered  this  and 
weighed  the  abilities  of  the  small  team  and  their  ability  to  work  together,  and,  by  mutual 
consent  with  the  approval  of  the  program  lead,  made  the  decision  to  implement  the 
approach. 

5.  Technical  Reviews 

a.  Description  of  Technical  Reviews  From  Guidance 

Technical  reviews  are  major  milestones  in  the  life  of  a  program.  These  are 
typically  used  as  approval  gates  for  forward  progress.  Technical  review  milestones  most 
often  follow  the  same  order  and  have  a  prescribed  content  per  standard  SE  guidance.  The 
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SMC  SE  Primer  describes  them  as  “requirements  reviews,  design  reviews,  and 
configuration  audits”  and  describes  that  they: 

Provide  an  opportunity  to  assess  program  status  in  considerable  detail.  In 
particular,  requirements  and  design  reviews  can  be  essential  to  monitoring 
at  points  in  the  program  prior  to  the  availability  of  test  and  other 
verification  data  that  provide  a  direct  indication  of  contract  compliance. 

(p.  89). 

The  milestones  that  are  commonly  part  of  an  acquisition  are  summarized,  in  order  of 
occurrence,  in  Table  11,  taken  from  section  1.5  of  the  Aerospace  SV  SE  handbook,  which 
is  consistent  with  the  DAG. 
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Integrated  Baseline  Review  (IBR) 

Objective:  Obtain  agreement  between  the  program  office  and 
contractor  on  the  five  risk  areas:  technical,  schedule,  cost,  resource,  and 
management  processes. 

Occurs:  As  soon  as  practical  after  the  contract  award,  and  following 
every  KDP  thereafter. 

Key  Outcome:  Agree  on  a  plan  of  action  to  handle  the  identified  risks. 

System  Requirements  Review  (SRR) 

Objective:  Review  requirements  and  requirement  flow-down. 

Occurs:  Approximately  twelve  months  after  contract  go-ahead. 

Key  Outcome:  Freeze  system  requirements  and  establish  a  functional 
baseline  design. 

System  Design  Review  (SDR) 

Objective:  Contractor  establishes  the  system  baseline  design,  allocates 
requirements  to  the  segment  level,  and  ensures  verification  planning  is 
adequate  at  the  system  and  segment  levels. 

Occurs:  When  design  has  proceeded  to  the  point  where  requirements 
have  been  allocated  to  elements. 

Key  Outcome:  Establish  a  system  design  specification  baseline. 

Preliminary  Design  Review  (PDR) 

Objective:  Establish  a  preliminary  baseline  design  for  eveiy  Cl. 

Occurs:  Within  eighteen  months  of  SRR  completion.  A  PDR  shall  be 
conducted  for  each  Cl  and  one  for  the  system. 

Key  Outcome:  Establish  a  “design-to”  Cl  baseline. 

Critical  Design  Review  (CDR) 

Objective:  Final  review  of  baseline  design  before  manufacturing. 

Occurs:  Within  eighteen  months  of  PDR  completion.  A  CDR  shall  be 
conducted  for  each  Cl  and  one  for  the  system. 

Key  Outcome:  Freeze  design  changes,  establish  a  “build-to”  for  all 
C’ls.  and  stait  manufacturing  configured  items. 


Table  11.  List  of  Program  Milestones  (SV  SE  Handbook,  p.  8) 
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Standard  SE  guidance  from  the  SV  SE  handbook  goes  on  to  describe  that 
two  of  these  reviews,  PDR  and  CDR,  are  each  not  to  be  conducted  as  single  review  rather 
“are  a  summary  of  progressive  or  incremental  reviews  that  start  with  specific 
configuration  items  (Cl’s),  then  assemblies  or  subsystems,  and  culminate  in  a  system- 
level  review.”  (SV  SE  Handbook,  sec  2.4. 1.3,  p.  40).  This  is  corroborated  by  the  DAG 
sec  4. 3. 3.4. 2.  in  saying, 

For  complex  systems,  a  CDR  may  be  conducted  for  each  subsystem  and 
logistics  element.  These  incremental  reviews  lead  to  an  overall  system 
CDR.  Incremental  design  reviews  are  usually  defined  at  Interface  Control 
Document  boundaries,  (p.  240) 

Standard  SE  Guidance  provides  more  direction  for  technical  reviews 
regarding  when  the  program  has  the  technical  review,  as  well  as  the  means  by  which  the 
program  judges  the  criteria  and  readiness  of  the  program  for  a  particular  review.  DoD 
instruction  5000.02,  in  the  Technical  Reviews  section  states: 

Technical  reviews  of  program  progress  shall  be  event-driven  and 
conducted  when  the  system  under  development  meets  the  review  entrance 
criteria  as  documented  in  the  SEP.  They  shall  include  participation  by 
subject  matter  experts  who  are  independent  of  the  program  (i.e.,  peer 
review),  unless  specifically  waived  by  the  SEP  approval  authority  as 
documented  in  the  SEP.  (p.  77). 

It  is  important  for  this  study  to  highlight  three  main  aspects  from  this  SE 
direction.  The  first  is  that  technical  reviews  shall  be  event  driven  (as  opposed  to  schedule 
driven)  and  follow  the  order  set  forth  in  guidance.  The  second  that  entrance  and  exit 
criteria  are  used  and  are  defined  previously  in  the  SEP,  or  at  least  identified  prior  to  the 
beginning  of  the  program  (ANSI/EIA  632  Req  5  g,  p.  12).  Thirdly,  that  there  should  be 
participation  by  subject  matter  experts  who  are  independent  of  the  program. 

The  DAG  shows  its  support  of  these  same  points  by  quoting  DoD  5000.02 
directly  then  expanding  on  the  themes  in  section  4.3  (p.  208).  As  well  as  corroborating 
the  direction  given  in  DoD  5000.02,  the  DAG  makes  an  additional  recommendation 
regarding  technical  reviews.  Section  4.3  states  “To  assist  in  the  preparation  for  and 
conduct  of  technical  reviews  technical  review  risk  assessment  checklists  are  available  for 
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each  of  the  reviews.”  (209).  These  “checklists”  are  a  recommended  approach  for  defining 
the  content  of  each  of  the  reviews  as  well  as  a  tool  to  assess  the  completeness  of  the 
review. 

Note:  Guidance  from  the  DAG  is  intended  in  the  context  of  a  major 
program  of  record  (JCIDS).  The  DAG  makes  reference  to  significant  lead  times 
necessary  to  prepare  for  these  significant  events  and  how  material  developed  in  pre¬ 
acquisition  may  be  needed  to  be  used  as  inputs  in  this  material  (sec  4.3,  p.  209).  This 
reference  is  clearly  made  in  the  paradigm  of  a  major  A,  B  &  C  Milestone  event  type 
program.  An  assumption  was  made  in  applying  SE  direction  for  accomplishing  a  major 
program  milestone  such  as  PDR  or  CDR  to  a  similar  event  held  for  a  pre-acquisition  type 
technology  demonstrator  like  SASSA.  It  was  viewed  as  applicable  in  the  sense  that,  when 
a  program  holds  a  major  event  like  CDR,  there  are  only  a  few  sources  that  can  be  used  as 
examples  to  provide  a  template  for  what  the  event  should  be  like  and  the  content  it  should 
have,  albeit  used  as  a  starting  place  for  tailoring.  If  this  type  of  guidance  was  not  used 
due  to  its  inapplicability,  and  if  taken  in  the  strictest  sense,  then  there  would  be  no 
guidance  available  for  a  SASSA-type  program’s  milestone  event. 

b.  SASSA  Tailored  Technical  Reviews  as  Implemented 

The  SASSA  program  identified  its  major  and  minor  sets  of  program 
milestones  to  be  accomplished  in  the  Integrated  Master  Plan  (IMP),  as  identified  in  sec 
6.2.5,  Attachment  CD4  to  the  SASSA  RFP.  Milestones  are  identified  as  either  an  Event 
(E)  or  a  Significant  Accomplishment  (SA).  The  list  of  Events  is  listed  in  Table  12  and  the 
list  of  Significant  Accomplishments  is  listed  in  Table  13. 


1.  SASSA  Integrated  Baseline  Review  (IBR) 

2.  SASSA  System  Requirements  Review  (SRR) 

3.  SASSA  System  Interim  Design  Review  (IDR) 

4.  SASSA  System  Critical  Design  Review  (CDR) 

5.  SASSA  Pre-ship  to  SV  Host  Review 

6.  System  and  Segment  On-orbit  Test  Completion  Review 

Table  12.  SASSA  Events  (SASSA  RFP  Attachment  CD-4,  p.  36) 


(NOTE:  The  IDR  event  is  very  similar  to  a  PDR  cited  in  SE  guidance.) 
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1.  SASS  A  Kick-off  Meeting 

2.  SASS  A  Testbed  Design  Review 

3.  SASSA  Software  Specification  Review  (SSR) 

4.  SASSA  Testbed  Certification  (TC) 

5.  SASSA  AI&T  Start 

6.  SASSA  Mission  Readiness  Review  (MRR) 

7.  Support  to  SV  Host  Flight  Readiness  Review  (FRR) 

8.  Support  to  SV  Host  Launch  Readiness  Review  (LRR) 

9.  Support  to  SASSA  Launch 

Table  13.  SASSA  Significant  Accomplishments  (SASSA  RFP  Attachment  CD-4,  p.  36) 


Directly  after  contract  award  the  SASSA  program  made  a  decision  on  the 
order  that  the  milestones  would  be  conducted.  The  order  that  the  milestones  were 
executed  is  listed  in  Table  14  with  (E)  for  Standard  Event  and  (SA)  for  a  Significant 
accomplishment. 


1.  SASSA  Kick-off  Meeting  (SA) 

2.  SASSA  System  Requirements  Review  (SRR)  (E) 

3.  SASSA  Integrated  Baseline  Review  (IBR)  (E) 

4.  SASSA  Software  Specification  Review  (SSR)  (SA) 

5.  SASSA  System  Interim  Design  Review  (IDR)  (E) 

6.  SASSA  System  Critical  Design  Review  (CDR)  (E) 

Table  14.  SASSA  Milestones  Conducted 


After  the  initial  Kick-off  meeting  with  each  contractor,  the  SASSA 
program  decided  to  accomplish  the  SRR  first  followed  by  the  IBR,  despite  the  traditional 
reversed  order.  The  next  milestone  in  order  following  the  IBR  was  the  IDR  (Interim 
Design  Review),  which  acted  as  a  progress  review  between  SRR  and  CDR  in  place  of  a 
PDR. 

Each  of  the  cited  standard  SE  documents  provides  guidance  on  using 
major  milestones  in  order  to  assess  maturity  before  proceeding  to  the  next  major  phase  of 
an  acquisition.  SE  guidance  also  directs  when  and  where  milestone  entry  and  exit  criteria 
should  be  generated  and  content  checklists  for  each  event.  Aside  from  these  examples, 
however,  there  is  no  other  instruction  for  the  execution  of  the  events.  In  order  to  prevent 
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major  schedule  setbacks  due  to  inadequate  maturity  at  the  milestone  reviews,  it  was 
imperative  that  the  correct  material  be  provided  and  reviewed  efficiently.  Thus,  the 
SASSA  program  developed  a  methodology  out  of  this  need  to  emphasize  program 
momentum  in  order  to  maintain  cost  and  schedule  goals  for  the  24-month  delivery. 

The  first  aspect  of  the  SASSA  process  was  to  create  and  expose  the 
contractor  to  the  milestone  entry  and  exit  criteria  for  the  event.  The  SASSA  program 
developed  its  own  entry  /  exit  criteria  tailored  from  standard  guidance  sources  such  as 
MIL-STD  1540,  MIL-STD  499B,  and  MILSTD  2167.  The  government  team  created 
them  prior  to  each  event  (8-12  weeks  out)  and  discussed  them  with  the  contractor.  The 
next  step  was  to  set  up  a  review  schedule  leading  up  to  the  event.  A  goal  for  this  was  to 
provide  a  means  to  review  the  material  for  content  and  presentation,  judging  it  against  the 
entry  criteria  for  a  sufficient  level  of  maturity.  The  SASSA  team  decided  to  require  final 
presentation-quality  briefing  materials  and  supporting  data  30  days  prior  to  the  event. 

Once  material  was  received,  the  SASSA  team  followed  an  aggressive 
internal  review  process  designed  to  assess  the  quality,  clarity,  completeness,  and  maturity 
of  the  material.  A  series  of  iterative  cycles  occurred  where  the  government  team  shared 
their  findings  with  the  contractor  and  subsequent  corrected  material  was  provided.  Figure 
8  depicts  this  process  over  the  30-day  review  cycle. 

Approximately  two  weeks  prior  to  the  event,  a  meeting  was  held  to 
discuss  the  readiness  of  the  contractor  to  conduct  the  review.  This  meeting  was 
commonly  referred  to  as  the  “Go/No  Go”  meeting.  If  sufficient  maturity  was  achieved 
against  the  criteria,  then  the  contractor  was  contacted  in  the  following  days  to  share  with 
them  the  entry  criteria  grading.  If  the  maturity  of  the  material  was  insufficient,  the 
milestone  would  be  delayed  with  specific  areas  to  be  addressed.  The  government  team 
would  work  issues  in  a  “shoulder-to-shoulder”-style  working  meeting  in  the  following 
days. 
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Task 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

Receive  Initial  Drop 

Gov  Review  (5-7  days) 

Go  /  No  Go  Meeting 

Comment  Review  w/  Ktr  (1-2  days) 

Ktr  Iterate  Material 

Drop  2 

Gov  Review  (2  days) 

Send  Drop  2  Comments 

Ktr  Iterate  Material 

Milestone  Event 

MTWRF  S  S  MTWRF  S  S  MTWRF  S  S  MTWRF  S  S  MTW 

Figure  8.  Example  SASSA  Milestone  Review  Schedule 


The  end  result  of  this  iterative  process  was  a  good  screening  for  maturity 
and  major  issues  early.  This  minimized  the  possibility  that  there  were  major  surprises 
discovered  at  the  event,  which  could  cause  significant  schedule  delays.  This  also  left  a 
moderate  amount  of  time  to  work  questions  and  issues  prior  to  the  event  so  that,  going 
into  the  event,  the  majority  of  these  were  resolved.  The  strategy  adopted  was  to  do  the 
majority  of  the  work  prior  to  the  event  so  that  the  event  itself  could  be  focused  on  the 
summary  of  all  the  material  as  a  wrap-up  and  culminating  event  vice  the  start  of  the 
review  process. 

At  the  conclusion  of  the  milestone  event,  the  government  team  would 
caucus  and  build  an  out-brief  presentation  given  on  the  last  day  of  the  meeting.  It  would 
consist  of  a  recap  of  the  entry  criteria  grading  and  would  highlight  any  areas  of  concern. 
It  would  then  provide  a  grading  against  the  exit  criteria  and  recap  any  significant  issues 
and  action  items  captured.  This  presentation  would  be  briefed  by  the  government, 
typically  the  SASSA  program  manager,  to  the  program  management  team  of  the 
contractor.  This  extra  effort  by  the  government  team  was  extremely  well  received  by  the 
contractor.  This  process  provided  immediate  feedback,  which  was  very  rewarding  to  the 
contractor. 

The  milestone  event  process  concluded  with  “action  items”  being  captured 
from  the  event  and  the  government  team  requiring  the  contractor  to  provide  an  action- 
item  closure  plan  for  each  action.  Since  major  issues  would  have  kept  the  event  from 
occurring,  these  actions  were  typically  not  major  program  or  technical  issues. 
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Occasionally  a  significant  issue  would  be  “discovered”  in  the  course  of  the  event  review 
and  would  need  to  be  adjudicated  in  short  order.  When  these  action  item  closure  plans 
were  provided,  the  government  would  officially  close  the  event. 

c.  Comparison  of  Standard  Guidance  to  SASSA 

The  first  and  most  apparent  deviation  the  SASSA  program  took  was  to 
conduct  the  System  Requirements  Review  (SRR)  as  the  first  major  event.  A  typical  order, 
following  standard  SE  direction,  a  program  would  hold  post  Kick-off  is  IBR.  This  is 
normally  due  to  the  fact  that  the  IBR  establishes  the  “baseline”  of  resources  allocated  to 
tasks,  schedule,  and  the  overall  implementation  of  the  program  budget.  It  is  often  viewed 
as  necessary  to  accomplish  this  event  before  anything  else.  The  SASSA  team  knew  that 
an  IBR  needed  to  be  conducted  quickly.  However,  given  the  extremely  intense 
development  schedule  of  only  24  months,  the  most  beneficial  task  to  be  accomplished 
first  was  for  all  organizations  to  agree  on  the  requirements  of  the  program.  Not  only  was 
this  viewed  as  an  important  place  to  start  the  program  with  the  contractors,  it  was  viewed 
as  a  beneficial  input  to  the  developing  of  the  baseline  for  IBR. 

The  second  deviation  SASSA  implemented  was  two-fold.  The  first  was 
the  choice  to  generate  the  technical  milestone  entry  and  exit  criteria  within  the  team, 
rather  than  simply  use  the  milestone  event  checklists  available  in  the  standard  SE 
guidance  texts.  The  second  was  to  develop  the  criteria  8-12  weeks  before  the  event  rather 
than  before  the  program  started  and  formalize  it  in  a  SEP  type  document.  This  was 
obviously  in  part  because  the  SASSA  program  did  not  have  a  standard  SEMP  or  SEP. 
However,  every  effort  was  made  to  consult  current  industry  best  practices  and  standard 
SE  guidance  checklists  for  milestone  content  and  criteria  as  inputs  from  which  SASSA 
entry  and  exit  criteria  were  tailored. 

The  next  deviation  SASSA  made  was  regarding  participation  by  subject 
matter  experts  who  are  independent  of  the  program.  SASSA  did  not  accomplish  this  in  a 
strict  sense  where  a  completely  independent  team  is  brought  in  to  assess  a  design  review 
or  technical  milestone.  Rather,  SASSA  did  rely  on  the  Aerospace  Corporation  “matrix” 
personnel.  These  are  FFRDC  technical  experts  in  various  fields  who  can  be  hired  by  the 
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government  team  to  assess  the  maturity  of  a  particular  area.  SASSA  also  invited  members 
of  organizations  who  showed  interest  in  the  SASSA  program  from  various  locations 
within  the  military  to  participate  in  major  reviews.  SASSA  made  routine  use  of  these 
experts  throughout  the  program  in  all  major  design  reviews.  These  personnel  then  acted 
as  pseudo  independent  (attended  repeated  events)  evaluation  sources  as  the  same  people 
for  certain  niche  fields  would  be  brought  in  but  who  did  not  work  the  program  in  a  day- 
to-day  manner. 

The  final  modification  that  SASSA  made  from  standard  SE  guidance  was 
to  not  adopt  the  systematic,  incremental  build  up  of  lower  level  units  or  segments  into  a 
system  level  technical  milestone  event  (PDR  &  CDR).  For  example,  in  the  SASSA 
structure  for  IDR  (SASSA’s  PDR  like  event),  this  would  have  looked  like  a  mini-PDR  or 
technical  review  at  each  of  the  unit  levels  (CIU,  RWR,  MCU-110,  Ground  Units,  etc), 
followed  by  a  segment-level  PDR  review  for  Space,  Ground,  and  Testbed,  all 
culminating  in  a  System  PDR.  While  standard  SE  guidance  and  good  design  practice 
(especially  for  large  programs),  this  approach  was  viewed  as  an  extremely  time-  and 
resource-intensive  approach.  For  SASSA,  the  benefits  did  not  outweigh  the  costs  to  the 
program,  which  would  likely  have  put  meeting  the  24-month  schedule  at  significant  risk. 

6.  Integrated  Product  Team  (IPT)  Structures 

a.  Description  of  Integrated  Product  Teams  (IPT)  in  Standard  SE 
Sources 

A  very  common  and  pervasive  standard  SE  guidance,  including  in  space 
acquisitions  at  SMC,  is  the  use  of  Integrated  Product  Teams  or  IPTs.  One  source 
describes  the  genesis  of  IPTs  by  saying: 

IPTs  evolved  as  a  response  to  “stove-piped”  engineering  organizations  in 
which  producibility  or  reliability  specialists,  as  examples,  might  NOT  be 
integrated  into  the  design  activity  with  the  result  that  the  associated 
constraints  might  be  given  inadequate  attention  or  “band-aided”  late  in  the 
development  with  a  resultant  lack  of  balance  in  the  design.”  (SMC  SE 
Primer,  p.  35) 
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IPTs  form  organizations  into  functional  or  logical  groups  for  the  purposes 
of  better  cross-organizational  communication.  Government  program-management  teams 
and  contractor  teams  alike  are  almost  exclusively  arranged  or  are  required  to  be  arranged 
in  an  IPT  structure.  Each  IPT  in  this  structure  has  a  government  and  contractor  lead. 
These  IPTs  can  be  very  formalized,  with  a  charter,  schedule,  and  deliverables  between 
IPTs;  or  they  can  be  very  informal,  put  together  for  a  short  period  to  address  a  specific 
issue  or  problem  (as  in  the  use  of  “tiger  teams”).  Figure  9  illustrates  the  SMC  SE 
Primer’s  example  of  a  generic  IPT  implementation  (Figure  46.  IPT  Typical 
Organizational  Structure,  p.149) 


Subsystem  A  IPT 

Figure  9.  Typical  Organizational  Structure 

Direction  for  use  of  IPTs  in  SE  guidance  texts  is  pervasive.  The  INCOSE 
SE  handbook  (p.  185-195),  discusses  at  length  the  historical  transition  from  development 
done  in  series  (one  task  accomplished  before  the  next)  to  IPTs  with  recognized  benefits. 
As  the  IPT  paradigm  matured  it  led  to  the  current  Integrated  Product  and  Process 
Development  (IPPD)  and  Integrated  Product  Development  Teams  (IPDT)  vernacular  and 
process.  Another  SE  guidance  source,  DoD  Directive  5000.1,  states  in  the  Collaboration 
section  that  “...programs  shall  maintain  continuous  and  effective  communications  with 
each  other  by  using  Integrated  Product  Teams  (IPTs)”  (El.  1.2.,  Enclosure  1  p.  5).  The 
SMC  SE  Primer  similarly  states: 
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The  key  organizational  building  blocks  are  Integrated  Product  Teams 
(IPTs)  and  cross-product  teams  such  as  System  Engineering  and 
Integration  Teams  (SEITs)  ....Each  Contractor  IPT  is  assigned  full 
Responsibility,  Authority,  and  Accountability  (RAA)  for  its  assigned 
products,  (p.  148). 

The  Space  Vehicle  Systems  Engineering  Handbook,  in  sec  1.6.1, 
corroborates  the  theme  by  saying  “A  proven  method  of  improving  the  efficiency  of  the 
development  process  is  by  establishing  working  groups  and  IPTs.”  (p.  9)  It  also  states 
“The  program  office  should  ensure  that  IPTs  are  employed  on  the  program  as  an  element 
of  SE,  SV  SE,  and  subsystem  and  unit  design  management  implementation.”  (p.  9). 
Finally  the  DAG  corroborates  the  above  guidance  and  expands  specifically  on  the  SE  role 
in  IPTs  with 

Systems  engineering  participates  in  the  IPPD  through  a  systems 
engineering  working-level  IPT  (SE  WIPT).  The  program  lead  or  chief 
engineers  should  establish  an  SE  WIPT  to  support  the  accomplishment  of 
all  systems  engineering  tasks  and  support  efforts,  (p.  172) 

b.  SASSA  Tailored  IPT  Structure  as  Implemented 

(1)  SASSA  Government  Team  Organization.  The  current 
SASSA  government  team  program  structure  is  highly  a  function  of  the  SASSA  programs 
growth  over  time.  In  the  spring  of  2007,  a  single  Air  Force  officer  was  in  charge  of  the 
“SASSA  project.”  SASSA  was  one  of  a  dozen  projects  assigned  to  the  Air  Force  officer 
to  oversee.  When  SASSA  received  its  requested  funding,  the  officer  was  authorized  to 
hire  contracted  Systems  Engineering  and  Technical  Assistance  (SETA),  Aerospace 
Corporation  (FFRDC)  technical  support,  and  was  authorized  to  utilize  another  junior 
officer,  partial  time,  in  the  late  summer  and  fall  of  2007.  This  pattern  followed  as  the 
project  solidified  in  maturity  and  scope  definition  with  the  team  following  suit  to  its 
current  size.  From  one  officer  full  time,  to  two,  then  three  and  so  on  to  its  present  size  of 
three  officers,  one  full-time  aerospace,  five  full-time  SETA  support  staff,  and  various 
part-time  support  specialty  personal  (i.e.,  scheduling  and  FFRDC  technical  specialty 
expertise). 
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Early  in  the  program,  there  was  a  conscious  choice  to  not 
implement  an  IPT  structure.  The  SASSA  program  was  an  aggressive,  fast-paced  program 
with  high  expectations  to  deliver  on.  There  was  a  lot  to  be  accomplished  with  very  little 
resources  in  the  government  office  in  just  getting  the  project  started.  A  strategy  was 
adopted  from  the  beginning  that  the  entire  team  was  responsible  for  knowing,  reading, 
and  accomplishing  everything.  The  SASSA  team  operated  as  a  “badgeless”  team, 
adopting  a  flat  organizational  structure.  For  SASSA  to  be  effective  in  starting  up  quickly 
then  all  people  needed  to  work  and  to  contribute  in  a  variety  of  fields  that  crossed  many 
traditional  roles.  In  this  manner,  the  entire  team  could  be  current  on  all  events  and 
involved  in  all  decisions.  Specific  tasks  were  volunteered  for  or  assigned  to  be  executed 
by  the  officer  in  charge  using  the  “best  athlete”  mentality.  In  this  way,  the  team’s 
experience  and  skills  were  maximized  across  the  program  as  everyone  was  exposed  to 
everything.  The  best  person  for  the  job  took  the  responsibility  of  accomplishing  specific 
tasks  or  was  assigned  to  specific  tasks  to  maximize  efficiency.  This  structure  avoided 
personnel  being  able  to  “hide”  under  IPT  titles  and  only  do  what  was  directly  applicable 
to  their  IPT.  Having  these  types  of  potential  inefficiencies  could  create  significant  drains 
in  a  small  team  who  needed  everyone  contributing  across  the  board,  regardless  of  IPT 
role. 

As  the  full  scope  of  the  SASSA  program  was  realized,  to  include  a 
dual  contract  award  (later  scaled  back  to  one),  two  full  SASSA  systems  being  procured, 
and  firm  relationships  on  two  separate  host  vehicles,  it  was  clear  greater  organization  was 
necessary.  The  total  body  of  possible  infonnation  on  the  program  became  too  large  for 
the  previous  “everyone  knows  everything”  mentality.  Thus,  a  pseudo  IPT  structure  was 
adopted.  This  was  pseudo  in  the  sense  that,  for  the  first  time  in  the  SASSA  organization 
structure,  an  individual  was  assigned  a  particular  specialty.  For  SASSA,  this  was  two 
individuals — a  software  lead  and  ground  lead.  Even  in  this  new  configuration  with  two 
focus  area  leads,  there  are  still  no  IPTs.  These  individuals  are  responsible  for  their 
particular  area  but  do  not  exist  as  or  within  an  IPT,  nor  do  they  lead  an  IPT  for  that 
subject.  All  personnel  still  perform  in  a  “floating”  mode  as  cross  program  help,  including 
these  two  leads,  albeit  in  a  secondary  role.  For  example,  multiple  SETA  staff  have 
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experience  in  a  variety  of  areas  including  program  management,  prior  military  acquisition 
experience,  business,  contracts,  security,  senior-level  technical  knowledge,  and  systems 
engineering.  These  personnel  maintained  a  high  resolution  of  knowledge  on  all  aspects  of 
the  program  and  bolstered  areas  as  needed,  without  existing  in  a  specific  IPT  or  lead  role. 

(2)  SASSA  Contractor  Team  IPT  structure.  The  SASSA 
program  required  both  contractors  to  adopt  a  conventional  IPT  structure  as  part  of  the 
proposal  process.  This  organizational  structure  remained  throughout  the  contractor’s 
contractual  period  of  perfonnance.  There  was  no  modification  of  this  aspect  of  standard 
SE  guidance  on  the  SASSA  program. 

c.  Comparison  of  Standard  Guidance  to  SASSA 

The  SASSA  program  tailored  standard  SE  guidance  in  one  significant 
respect.  This  was  to  intentionally  not  adopt  a  strict  IPT  structure  for  the  government  team 
at  any  point  in  the  program.  Even  currently,  the  structure  reflects  more  that  certain 
individuals  have  areas  of  focus  rather  than  being  the  lead  of  an  IPT  element.  This  is  also 
made  clear  by  the  lack  of  complete  IPT  elements  across  the  current  structure.  For 
example,  there  is  no  space  segment  or  single  SE  lead.  The  primary  reason  for  SASSA 
government  team  not  adopting  a  strict  IPT  structure  was  an  attempt  to  implement  a 
strategy  to  better  maximize  the  efficiency  of  the  government  team  in  accomplishing  the 
large  amounts  of  diverse  work. 
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V.  EVALUATION  OF  SASSA  TAILORED  SYSTEMS 
ENGINEERING  PROCESSES 


A.  INTRODUCTION 

This  chapter  assesses  the  standard  SE  processes  that  have  been  tailored  for  their 
contributions,  positively  and  negatively,  towards  achieving  a  rapid  space  acquisition  in 
the  SASSA  program.  The  utility  of  this  assessment  is  aimed  at  providing 
recommendations  for  utilization  of  selected  tailored  SE  processes  for  similar  acquisition 
projects,  as  well  as  capture  historical  infonnation  for  the  reader.  The  lessons  learned  on 
this  program,  specific  to  a  rapid  space  acquisition  and  the  unique  attempts  made  in  both 
effort  and  methodology,  may  be  of  usefulness  for  similar  programs  in  the  future. 

B.  STANDARD  CRITERIA  FOR  EVALUATING  TAILORED  PROCESSES 

This  section  identifies  criteria  by  which  each  of  the  tailored  SE  processes  can  be 
judged  against  in  assessing  whether  the  process  was  a  positive  or  negative  contribution  in 
accomplishing  the  SASSA  rapid  space  acquisition.  These  criteria  describe  various  aspects 
of  value  in  the  tailored  processes.  The  criteria  are: 

•  Meeting  program  technical  or  programmatic  objectives 

•  Reducing  cost 

•  Maintaining  or  shortening  schedule 

•  Contributing  to  the  ease  of  the  SE  process 

•  Contributing  to  the  quality  of  the  SE  process 
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c. 


SASSA  TAILORED  SYSTEMS  ENGINEERING  PROCESSES 
EVALUATION 


1.  Requirements  Development 

The  major  deviations  from  the  SE  guidance  for  Requirements  Development  are 
summarized  as: 

•  SASSA  did  not  utilize  the  JCIDS  (ICD  or  CDD)  or  their  development 
approaches  as  suggested  in  SE  guidance 

•  SASSA  did  not  have  any  fonnal  stakeholder  input 

•  SASSA  did  not  utilize  fonnal  KPP/KPA’s  at  the  government  level 

The  tailored  implementations  by  SASSA  are  summarized  as: 

•  SASSA  assumed  the  congressional  language  as  a  starting  place  and  developed 
program  objectives  and  a  TRD  traceable  to  these  objectives 

•  SASSA  applied  internal  expertise  and  understanding  of  SSA  to  the  needs  of 
the  SASSA  system  in  requirements  development 

•  SASSA  utilized  a  minimum  number  of  requirements  in  the  TRD 

•  SASSA  utilized  an  Excel  spreadsheet  to  capture  requirements  traceability, 
capabilities,  and  verification  information  for  ease  of  assessment  and 
effectiveness 

•  SASSA  developed  a  three  volume  SASSA  SIS  ICD  for  instrument  and  SV 
hosts  to  understand  the  SASSA  interfaces 

The  approach  the  SASSA  program  implemented  for  tailoring  the  standard  SE 
guidance  for  the  requirements  development  process  approach  was  assessed  as  very 
successful  towards  completing  the  rapid  space  acquisition.  The  process  tailoring  enabled 
the  program  to  develop  sufficient  requirements  for  the  rapid  acquisition  quickly.  The 
process  rigorously  decomposed  these  requirements  and  ensured  appropriate  mapping 
from  the  original  congressional  language,  to  the  programs  core  objectives,  to  the  TRD 
requirements.  Total  program  cost  and  schedule  was  saved  through  implementing  wise 
choices  in  software  tools,  which  optimized  efficiency  of  assessment  and  depth  of  SE 

review.  Establishing  a  minimum  number  of  TRD  requirements  also  streamlined  efforts 
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and  reduced  total  requirements  management  overhead.  This  rapid  process  established 
solid  requirements  quickly,  allowing  the  program  to  contribute  to  future  SASSA 
programs’  SE  effort  in  the  development  of  the  SIS  ICD  volumes.  In  summary,  the 
program  was  able  to  complete  all  the  requirement  documents  to  ensure  that  all  the  design 
reviews  were  completed  on  schedule.  The  requirements  development  process  completely 
captured  the  customer  needs,  which  are  currently  being  verified  as  part  of  system  tests. 
The  results  of  the  tailored  processes  only  contributed  to  efficiency  and  expediency  in  the 
overall  acquisition. 

2.  Functional  Architecture  Design  and  Synthesis 

The  major  deviations  from  the  SE  guidance  for  Functional  Architecture  and 
Design  Synthesis  are  summarized  as: 

•  SASSA  constrained  the  possible  architecture  and  synthesis  solutions  by 
constraining  implementations  with  the  technical  requirements 

The  tailored  implementations  by  SASSA  are  summarized  as: 

•  SASSA  performed  an  analysis  of  alternative  type  study  with  a  reference 
system  design 

•  SASSA  implemented  a  particular  architecture  as  a  starting  place  for  contractor 
design  including  a  secondary  payload  configuration,  high  TRL  hardware,  and 
defined  payload  elements  with  space,  ground,  and  testbed  segment 
delineations 

The  approach  the  SASSA  program  implemented  for  tailoring  the  standard  SE 
guidance  for  the  Functional  Architecture  and  Design  Synthesis  process  was  assessed  as 
very  successful  towards  completing  the  rapid  space  acquisition.  The  tailored  process 
constrained  the  scope  of  the  problem  to  be  solved  given  the  funding,  schedule,  and 
resources  available.  This  focused  contractor  efforts  that  aided  in  maintaining  efficient 
expenditure  of  cost  and  schedule  resources  in  achieving  a  successful  design 
implementation.  The  decision  to  make  some  of  the  design  synthesis  choices  within  the 
government  office  as  a  starting  place  moved  the  contractor  design  implementation  farther 
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along  the  developmental  process  that  was  advantageous  in  meeting  the  rapid  acquisition 
timeline.  Achieving  this  design  earlier  in  the  timeline  also  allowed  more  rigorous  SE 
review  earlier  in  the  program.  Given  the  constraints  as  well  as  the  specific  set  of 
instruments  the  SASSA  team  gave  to  the  contractor,  it  eliminated  any  trade  analysis 
and/or  indecisions.  This  could  have  cost  the  program  precious  time  in  the  architecture 
definition  phase  and  delayed  the  start  of  specific  design.  Overall,  this  tailored  process 
used  by  SASSA  is  assessed  to  have  been  a  critical  positive  contributor,  essential  in 
achieving  successes  in  the  program  this  far  in  completing  the  rapid  space  acquisition. 

3.  Standard  Systems  Engineering  Plans 

The  major  deviations  from  the  SE  guidance  for  use  of  Standard  Systems 
Engineering  Plans  are  summarized  as: 

•  SASSA  did  not  develop  a  standard  SEP/SEMP,  SEMS  and/or  SEDS 

•  SASSA  did  not  require  their  contractors  to  develop,  maintain,  and  update  a 
standard  government  approved  SEP/SEMP,  SEMS  and  SEDS 


The  tailored  implementations  by  SASSA  are  summarized  as: 


•  SASSA  captured  SE  methodologies  by  implementing  a  multipronged 
approach: 

o  RFP  evaluation  criteria  for  processes  for  Systems  Engineering  and 
Software  Engineering  Management 
o  Contractor’s  proposal  response  to  the  RFP  for  these  criteria;  this 
articulated  the  contractors  process  and  plan  without  requiring  a 
standard  SEMP 

o  (IMS)  -  this  captured  major  SE  milestones  and  interrelations  to 
other  critical  events 

o  Specification  of  required  government  approved  contractual 
deliveries  (CDRLs)  CM,  PMP,  and  SDP 
o  Team  decided  before  program  execution  how  it  would  execute  SE 
in  the  program  -  captured  in  a  briefing 


The  approach  the  SASSA  program  implemented  for  tailoring  the  standard  SE 
guidance  for  utilizing  Standard  Systems  Engineering  Plans  was  assessed  as  very 
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successful  towards  completing  the  rapid  space  acquisition.  This  SASSA  process 
implementation  is  an  excellent  example  of  how  SASSA  was  able  to  effectively  tailor  a 
standard  SE  process  to  make  positive  contributions  towards  a  rapid  space  acquisition. 
The  upfront  RFP  planning  and  acquisition  requirements  which  the  contractors  had  to 
respond  to,  as  well  as  the  discussions  as  to  how  the  SASSA  team  would  manage  the 
development  contracts  accomplished  the  objectives  of  a  standard  SEMP/SED  without  the 
expenditure  of  the  associated  lengthy  time  and  resources.  Additionally,  the  contractor 
proposed  to  leverage  a  standard  SEMP  from  company  “Command  Media,”  which  helped 
set  the  framework  of  how  to  conduct  business.  This  was  stated  at  the  program  kick-off 
and  agreed  to  by  the  SASSA  program  office,  which  eliminated  the  need  for  a  lengthy 
SEMP  development  activity.  Overall,  the  tailored  approach  implemented  by  SASSA 
ensured  SE  objectives  for  the  program  were  met,  shortened  the  overall  schedule  by 
reducing  the  overall  tasks  to  be  accomplished,  and  contributed  to  cost  savings  by 
optimizing  time  and  task  expenditures. 

4.  Use  of  Systems  Engineering  Leads 

The  major  deviations  from  the  SE  guidance  for  the  use  of  Systems  Engineering 
Leads  are  summarized  as: 

•  SASSA  did  not  appoint  or  use  a  SE  lead  in  the  government  team 

The  tailored  implementations  by  SASSA  are  summarized  as: 

•  SASSA  performed  SE  as  a  group  and  by  consensus  on  the  government  team 

The  approach  the  SASSA  program  implemented  for  tailoring  the  standard  SE 
guidance  for  the  use  of  Systems  Engineering  Leads  was  assessed  as  a  neutral  contribution 
towards  completing  the  rapid  space  acquisition.  The  SASSA  program  was  able  to 
execute  and  maintain  excellent  SE  oversight,  but  it  could  not  be  attributed  to  the  process 
tailoring.  Rather  the  SASSA  team  exploited  an  advantageous  situation  with  many  on  the 
SASSA  team  having  education  and  predisposition  for  doing  systems  engineering.  A 
program  that  chooses  to  implement  this  same  tailoring  approach  risks  not  ensuring  that 
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adequate  expertise  in  SE  is  a  part  of  the  program  or  that  adequate  SE  work  is  being 
accomplished  on  the  program.  The  conclusion  is  the  successes  on  the  SASSA  program  in 
this  area  were  due  more  to  the  team  composition  than  the  tailoring  of  the  standard  SE 
process.  This  approach  should  be  viewed  as  a  risk  for  any  program  considering  this 
implementation,  noting  that  success  is  critically  dependant  on  team  composition 
throughout  the  life  of  the  program. 

5.  Technical  Reviews 

The  major  deviations  from  the  SE  guidance  for  Technical  Reviews  are 
summarized  as: 

•  SASSA  milestones  were  out  of  order  from  guidance 

•  SASSA  did  not  develop  entry  and  exit  criteria  before  the  program  was  started 
nor  did  it  put  it  in  the  SEM  or  SEMP 

•  SASSA  did  not  use  a  completely  independent  team  to  review  technical 
milestones 

•  SASSA  did  not  use  incremental  milestone  reviews  from  unit  to  system  for 
PDR  and  CDR 

The  tailored  implementations  by  SASSA  are  summarized  as: 

•  SASSA  performed  SRR  before  IBR  as  its  first  major  milestone 

•  SASSA  developed  entry  and  exit  criteria  within  the  government  team  8-12 
wks  prior  to  the  event 

•  SASSA  utilized  FFRDC  and  outside  organizational  experts  for  IDR/CDR 
(with  every  review) 

•  SASSA  held  a  single  milestone  event  for  all  elements  with  exception  of 
Software  at  SRR  (SSR) 

•  SASSA  performed  a  rigorous  early  technical  review  preparation  process  (30 
day  plan) 

The  approach  the  SASSA  program  implemented  for  tailoring  the  standard  SE 
guidance  for  Technical  Reviews  was  assessed  as  very  successful  towards  completing  the 
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rapid  space  acquisition.  The  first  positive  contribution  from  the  modification  of  this 
guidance  by  SASSA  is  an  early  aligning  and  understanding  by  the  contractor  of  the 
system  requirements.  This  was  a  critical  factor  is  setting  the  program  off  on  the  right  foot 
for  both  a  technical  understanding  and  the  opportunity  to  plan  the  program  resources. 
The  next  benefit  of  the  tailored  guidance  was  the  use  of  “semi-independent”  experts  to 
review  material  at  the  SASSA  milestones.  This  outside  perspective  added  to  the  rigor  of 
each  event  in  ensuring  adequate  SE  and  design  principles  had  been  used.  An  additional 
benefit  to  the  SASSA  tailored  guidance  was  in  saving  schedule  and  resources  (ultimately 
cost)  by  not  performing  incremental  technical  review  events  preceding  the  system 
technical  reviews.  SASSA  was  able  to  take  advantage  of  its  smaller  system  and  still 
accomplish  rigorous  technical  reviews.  The  final  positive  contribution  was  the  technical 
event  preparation  and  review  process  developed  by  the  SASSA  team.  This  process 
allowed  for  early  review  and  approval  prior  to  the  event,  which  allowed  for  more 
efficient  maintenance  of  technical  momentum  in  the  program  and  minimizing  the  risk  of 
significant  schedule  delays.  This  also  ensured  the  meeting  of  program  objectives  by 
upfront  review  as  a  forcing  function  for  maturity  assessment.  By  uncovering  issues  early 
in  milestone  preparation  process  SASSA  minimized  the  risk  of  spending  time  and 
resources  addressing  design  issues  and  actions  items  discovered  for  the  first  time  at  the 
event. 

The  SASSA  program  could  have  been  even  more  efficient  if  had  followed  the 
aspect  of  the  standard  guidance  for  completing  the  entry  and  exit  criteria  before  the 
program  start  as  well  as  described  the  milestone  event-review  preparation  process.  This 
would  have  allowed  the  contractor  to  plan  accordingly  with  time  and  resources.  This  may 
have  contributed  to  reducing  the  current  cost  overrun  in  the  SE  cost  element  in  the 
program. 

Overall,  the  process  tailoring  by  the  SASSA  program  for  Technical  Milestones 
was  beneficial  in  the  success  of  maintaining  the  milestone  schedule  of  events  from  kick¬ 
off  through  CDR  and  ensuring  in  depth  SE  and  design  reviews. 
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6.  Integrated  Product  Team  (IPT)  Structures 


The  major  deviations  from  the  SE  guidance  for  the  use  of  Integrated  Product 
Team’s  (IPT)  are  summarized  as: 


•  SASSA  government  team  did  not  utilize  a  rigid  IPT  structure,  even  late  into 
the  program 


The  tailored  implementations  by  SASSA  are  summarized  as: 
•  SASSA  utilized  a  flat,  organizationally  “badgeless”  team 


The  approach  the  SASSA  program  implemented  for  tailoring  the  standard  SE 
guidance  for  utilizing  IPTs  was  assessed  as  very  successful  towards  completing  the  rapid 
space  acquisition.  The  implementation  of  the  “flat”  organizational  structure  was  a 
significant  positive  contribution  to  the  overall  SASSA  rapid  acquisition.  The  lack  of  strict 
IPT  stovepipes  allowed  synergy  among  the  few  team  members,  which  was  critical  to 
accomplishing  the  large  volume  and  technical  depth  in  a  variety  of  fields  in  a  short  time. 
It  allowed  all  members  of  the  team  a  holistic  view  of  the  program  as  all  members  were 
current  on  all  topics.  It  efficiently  used  the  resources  of  the  team  and  minimized  the 
tendency  to  focus  only  on  an  individual  IPT  or  subject.  Overall,  the  SASSA  modification 
of  the  SE  guidance  to  implement  IPTs  was  assessed  to  be  a  great  positive  contributor 
towards  achieving  this  rapid  space  acquisition.  The  composition  of  the  SASSA  team  and 
individual  traits  of  the  members  allowed  for  a  more  beneficial  application  of  resources  in 
executing  the  program  than  could  be  had  by  implementing  an  IPT  structure. 

D.  CHAPTER  SUMMARY 


Table  15  summarizes  the  assessment  of  the  SASSA  tailored  standard  SE  guidance 


and  indicates  its  contribution  towards  accomplishing  a  rapid  space  acquisition. 


Modified  SE 
Process 

SASSA  Modifications 

Benefits 

Risks 

Contribution 

Requirements 

Development 

-  No  JCIDS  process 
involvement/  utilization 

-  No  formal  stakeholder 
involvement 

-  No  KPP/KPA’s 

-  Strong  traceability 
from  goals  to  req.’s 

-  Clear  traceability 
from  original  goals 
to  req.’s 

-  Allowed  program 
to  move  more 
quickly  than  a  JCIDs 
program 

-  Potential  lack  of 
insight  into  final 
capability  with  no 
interim  KPP/KPA 

assessment 

-  Output  capability  of 
program  not  useful  to 

Positive 
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users  (potential) 

Functional 
Architecture 
and  Design 
Synthesis 

-  Gov  imposed  design 
aspects  (TRL,  HW 
units,  heritage  req.’s) 

-  Defined  Functional 
elements 

-  Minimize 
inefficient/wasted 
design  effort 

-  Focus  program  on 
likely  solutions 

-  High  probability  of 
plausible  options 

-  Miss  inventive  or 
creative  solutions 

-  “Constrain  out” 
better  solution 

Positive 

Standard  SE 
Plans 

-  No  government  or 
contractor  SEP,SEMP, 
SEMS,  or  SEDS 
-Use of RFP,  IMS, 
CDRLs  for  SE  process 

-  Program  meetings  to 
define  processes 

-  Use  of  Contractor 
processes 

-  Saved  resources  for 
Gov  and  contractor 

-  Less  documentation 

-  Less  overall  tasks 

-  Gov  does  not  see 
potential  deficient  SE 
plans  of  contractor 

-  Gov  is  unclear  on 
its  own  SE 
plans/process 

Positive 

Use  of 

Systems 

Engineering 

Leads 

-  No  dedicated  SE  lead 
on  government  team 

-  Team  SE  process 

-  More  than  one  SE 

-  Diverse, 
collaborative  SE 
tracking 

-  Lack  of  adequate 

SE 

-  Inconsistent  SE 
process 

-  Critically  dependant 
on  team  composition 

Neutral 

Technical 

Reviews 

-  SRR  before  IBR 

-  Entry/Exit  criteria  not 
generated  before 
program  initiation 

-  Criteria  not  in 

SEM(P) 

-  No  completely 
independent  reviewers 

-  No  incremental 

reviews 

-  Superior 
knowledge  of 
program 
requirements  for 
baseline  planning 

-  Understand 
program  needs  from 
the  start 

-  Save  resources 

-  Thorough  reviews 

-  Contractor  not 
understanding  tech 
event  criteria  in 
planning  resources 
for  baseline 

-  Under  scope 
resources 

-  Too  much  in  one 
review  for  larger 
programs 

-  Miss  independent 
perspective 

Positive 

Integrated 

Product 

Teams  (IPT’s) 

-  “Flat”,  versatile 
government  team 
structure  vice  IPT 
structure 

-  More  expertise 
exposed  to  more 
tasks 

-  surge  capability  for 
quick  task 
completion 

-  Entire  team  up  to 
date  on  critical  issues 

-  Counteracts  stove 
piped  thinking 

-  Good  fit  for 
minimal  Gov 

resources 

-  Entire  team  aware 
of  program  status 

-  Too  much 
information  for  all  to 
absorb  as  program 
grows 

-  Lack  of  ability  to 
have  needed  depth  in 
focused  area  in  large 
programs 

-  Lack  of  consistent 
follow 

through/tracking  of 
single  segment  issues 

Positive 

Table  15.  Summary  of  Tailored  Standard  Systems  Engineering  Processes 
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VI.  APPLICATION  OF  STUDY 


A.  INTRODUCTION 

This  study  would  not  be  of  any  use  or  utility,  in  the  view  of  the  researcher,  if  it 
were  not  for  some  possibility  of  practical  application  that  has  the  ability  to  live  beyond 
the  simple  historical  analysis  of  the  SASSA  program.  The  first  and  foremost  intention 
for  the  application  of  this  study  is  for  similar  programs  to  be  able  to  observe  elements  of 
the  SASSA  program,  learn  from  the  perceived  successes  and  failures,  and  make  informed 
decisions  for  how  to  optimize  their  program.  The  second  intention  is  to  provide  useful 
information  for  the  general  education  of  the  systems  engineering  community  in  order  to 
stay  current  and  relevant  in  the  current  application  of  SE  on  a  DoD  space  program. 
Space  acquisitions  is  a  dynamic  and  changing  field  and  will  only  become  more  so  as  our 
reliance  on  and  capabilities  in  space  drive  greater  and  greater  population  of  space.  Threat 
warning  capability  for  satellites  is  currently  on  the  verge  of  universal  propagation  to  the 
same  degree  that  is  prevalent  on  terrestrial  airframes  and  military  ships.  Understanding 
how  SE  is  being  applied  in  the  far  comers  of  the  growing  fields  of  acquisitions  is 
essential  to  staying  relevant  and  current.  The  third  intention  for  the  application  of  this 
study  is  to  provide  readily  usable  recommendations  for  rapid-paced  acquisitions.  The 
final  intention  is  to  provide  feedback  and  recommendations  for  the  improvement  of  the 
overall  DoD  acquisitions  process,  specifically  in  the  early  Prephase  A  portions  of 
development  and  systems  engineering. 

B.  OBSERVATIONS 

•  Most  standard,  military  based  SE  guidance  is  primarily  SE  technical  management 
(vice  SE  processes) 

•  Most  industry  SE  guidance  is  so  high  level  it  is  either  not  useful  or  difficult  to 
apply/implement  in  a  DoD  military  acquisition 
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•  There  is  little  if  any  SE  guidance  for  non  JCIDs/formal  acquisitions,  despite  a 
large  number  of  military  programs  falling  outside  this  realm 

•  The  apparent  source  of  SE  processes  (not  technical  management  guidance) 
knowledge  is  either  learned  by  experience,  found  in  contractor  “command 
media,”  or  learned  in  academia.  This  relegates  SE  learning  by  handing  down 
“over  the  campfire”  by  those  more  experienced  who  tutor  younger  engineers  or 
via  higher  education 

•  Standard  SE  guidance  must  be  tailored/deviated  from  to  achieve  a  rapid 
acquisition 

•  Team  composition  is  equally  as  important  as  the  tailoring  of  standard  SE 
processes  in  rapid  space  acquisitions 

•  By  not  providing  directly  applicable  standard  guidance,  the  larger  DoD 
acquisition  system  creates  an  inherent  risk  and  inefficiency  by  allowing  non 
JCIDS  type,  smaller  programs  to  “fly  under  the  radar”  of  current  SE  guidance 

•  Adherence  to  good  SE  processes  is  as  important  as  having  defined  good  SE 
processes 

•  Value  added  should  be  the  strict  criteria  for  whether  or  not  a  tailored  or  standard 
SE  process  is  implemented 

•  “Better”  is  the  enemy  of  “good  enough” 

•  Tailoring,  where  possible,  should  apply  lessons  learned  from  other  acquisition 
activities 

•  Rapid  space  acquisition  s  requires  experienced  and  SE  knowledgeable  personnel  - 
these  programs  are  too  short  and  consequences  to  dire  to  leam  on  the  job 

•  Rapid  space  acquisition  requires  strong  SE  leadership  to  focus  effort 
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C.  RECOMMENDATIONS 

1.  Recommendations  for  the  Systems  Engineering  Community 

•  Perform  a  survey  of  SE  guidance  for  military  acquisitions  and  ensure  there  is 
comprehensive  coverage  of  SE  processes  (as  opposed  to  SE  technical 
management). 

o  Publish  a  Primer  which  points  to  or  consolidates  this  “how  to  do  SE  in  the 
military”  for  ease  of  use  and  proliferation,  focused  on  SE  processes. 

•  Create  a  new  SE  guidance  or  append  the  present  guidance  which  would 
instruct  on  how  to  practically  implement  and  accomplish  SE  processes  on 
non-formal/non  JCID’s  programs. 

•  Create  a  new  SE  guidance  or  append  the  present  guidance  for 
recommendations  on  how  to  tailor  standard  guidance  for  non-formal/  non 
JCIDs  programs. 

o  Address  the  importance  and  relationship  of  the  large  number  of  small 
technology  and  acquisition  efforts  to  the  larger  formal  programs  and 
JCIDS  process.  Good  SE  is  needed  even  in  these  small  programs  to  be 
efficient  in  technology  maturation  as  it  relates  to  larger  programs. 

•  Continue  to  instruct  in  basic  SE  application  and  build  a  strong  foundational 
knowledge  of  accomplishing  SE  processes  in  SE  students. 

o  Advocate  for  high  levels  of  practical  implementation  instruction  for  doing 
SE  in  military  programs  at  universities  and  especially  in  military  higher 
education  facilities. 


83 


2.  Recommendations  for  Accomplishing  Rapid  Space  Acquisitions 

•  Observe  and  consider  the  positive  contributions  made  on  the  SASSA  program 
by  tailoring  standard  SE  guidance 

•  Tailor  standard  SE  guidance  and  choose  quality  teams  using  “value  added”  as 
a  prime  criteria 

•  Ensure  processes  proposed  are  followed  throughout  acquisition  regardless  of 
if  they  were  tailored  or  not 

•  Assemble  teams  that  have  experienced  and  SE  knowledgeable  personnel  as  a 
“non-negotiable” 

•  Ensure  processes  proposed  are  followed  throughout  acquisition,  regardless  of 
if  they  were  tailored  or  not 

•  Provide  strong  SE  leadership  on  the  team 

D.  AREAS  FOR  FURTHER  RESEARCH 

Recommended  areas  of  further  research  fall  into  two  main  areas.  The  first  is  to 
take  the  assessments  of  tailored  processes  and  compare  them  for  validity  to  other 
programs  of  like  size  and  scope.  This  undertaking  would  aid  in  determining  whether  the 
assessments  of  the  tailored  processes  were  accurate,  whether  the  results  were  repeatable 
as  evidenced  by  other  programs,  or  whether  additional  processes  could  be  added  to  the 
recommendations.  Greater  confidence  in  the  recommendations  of  this  study  could  be 
achieved  if  it  is  compared  to  a  body  of  programs  rather  than  this  single  instance. 

The  second  area  of  additional  research  is  to  expand  on  the  concept  of  developing 
standard  SE  processes  guidance  for  smaller,  Prephase  A  programs.  This  study  could 
develop  a  series  of  aspects  to  include  the  validation  of  the  link  between  smaller  programs 
and  standard  JCID  milestone  programs  (i.e.,  feeder  programs),  a  more  complete  survey  of 
material  for  guidance  on  smaller  programs,  or  creating  a  draft  of  guidance  that  addresses 
various  solutions  for  how  standard  SE  guidance  might  look  for  smaller  programs. 
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APPENDIX  A.  ACQUISITION  DESCRIPTION  SUMMARY 


This  brief  summary  is  intended  to  accomplish  two  things.  The  first  is  to  provide  a 
working  knowledge  of  formal  acquisitions  processes  in  the  DoD  as  a  context  for  the  rest 
of  the  study.  The  second  is  to  capture  the  somewhat  unusual  acquisition  process  SASSA 
has  experienced  relative  to  the  fonnal  JCIDS  acquisition  process  in  the  DoD.  It  is  worth 
noting,  for  background  information,  what  the  typical  acquisition  process  is  and  its  phases, 
what  the  nonnal  products  of  each  phase  would  be,  and  how  SASSA  differed.  This  will 
serve  as  a  backdrop  for  the  entire  study,  keeping  in  mind  the  focus  of  the  study  is  to 
investigate  the  modification  of  typical  SE  processes. 

A  quick  refresher  on  DoD  acquisition  process  is  helpful  in  understanding  how  the 
SASSA  program  differed  in  its  start  up.  The  Chairman  of  the  Joint  Chiefs  Of  Staff 
Instruction,  JCSI  3170.01C,  24  June  2003  establishes  the  policies  and  procedures  of  the 
Joint  Capabilities  Integration  and  Development  System  (JCIDS)  (SMC  SE  Primer,  p.  39). 
The  JCIDS  development  system  is  the  current  DoD  architecture  in  which  all  major 
acquisitions  are  implemented.  Included  in  this  system  is  a  means  by  which  DoD 
acquisition  needs  are  identified,  investigated,  and  then  flowed  down  further  in  the 
process.  This  top-down  needs-identification  process  is  depicted  in  the  SMC  SE  Primer. 
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Decision  &  Acton 


JCIDS  top-down  capability  need  identification  process  (SMC  SE  Primer,  p.  40) 


Once  top-level  needs  have  been  identified,  they  are  flowed  to  the  next  phase  of 
the  JCIDS  process.  The  entire  life  cycle  of  the  JCIDS  process  is  depicted  in  both  a 
simplified  functional  sense,  as  well  as  in  the  formal  steps,  as  depicted  in  figures  1.6-1  and 
2.2-1  (SV  SE  Handbook).  In  general,  the  entire  JCIDS  process  is  broken  into  three  major 
milestone  phases:  A,  B,  and  C  (SMC  SE  Primer,  figure  12).  Each  phase  is  preceded  by 
standardized  and  gated  processes  that  have  to  be  approved  by  the  major  authority  placed 
over  the  acquisition. 


86 


Deployment 

(SV  SE  Handbook,  p.  1 1)  Simplified  functional  description  of  activities  completed  in  the 

JCIDS  process 


ODNRO 
I 'Approval 

Decision  ^  W  ^  Build Follow-on  A 

V  V  T  Approval's /  Buy\/ 

i  _ _ ,  i 


Concept 

Concept 

Preliminary 

Complete 

Build  & 

Studies 

Development 

Design 

Design 

Operations 

•  Study 

•  Develop 

•Complete 

•Complete 

•  Fabricate 

Alternative 

Technologies 

Technology 

Design 

System 

Concepts 

•  Define  Ops  & 

Development 

•  System 

System  Rqmts 

•Baseline 

Checkout 

•  Identify 

•  Conduct 

•  Preliminary 

Management/ 

•  Authority  to  Ship 

Potential 

-  Risk  Reduction 

Design 

Definitization 

•  On  Orbit  Test  & 

Solutions 

-  Trade  Studies 

Ops 

•  Define  Baseline 

•Baseline 

•  Upgrades 

•  Identify 

•  Initial  Design 

Management; 

Technology 

Definitization 

Pre-Phase  A 

Phase  A 

Phase  B 

Phase  C 

Phase  D 

Design 

Reviews: 

SRR  SDR 

r  PD* 

r  CDRf 

' 

▼  MDA  Key  Decision  Points  (KDP-A,  KDP-B,  KDP-C)  <^>  MDA  Program  Reviews 

Note:  On  NRO  programs,  Director  NRO  (DNRO)  approval 
substitutes  for  KDP-C.  I.e.,  No  NAB  convened  at  this  point. 


(SV  SE  Handbook,  p.  19)  JCIDS  Milestone  steps 
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CO 

CO 

> 


< 

CO 

9 

CJ 


*  IOC 


(SMC  SE  Primer,  p.  41)  Simplified  JCIDS  Milestone  Steps 


The  formal  JCIDS  process  can  be  described  in  detail  in  many  sources,  however 
the  relevant  aspect  for  this  study  is  the  initial  phase  where  requirements  have  been 
identified  or  need  to  be  identified  and  are  initiated  in  the  JCIDS  process.  In  the  JCIDS 
vernacular  this  is  the  Pre-milestone  A  phase  or  Prephase  A.  This  phase,  as  with  each  of 
the  phases,  has  a  prescribed  set  of  content  that  needs  to  be  addressed  and  approved  to 
move  to  the  next  phase. 

The  SV  SE  handbook  describes  the  content  that  Prephase  A  is  intended  to  capture 
by  stating, 

Prephase  A  is  characterized  by  development  and  evaluation  of  alternative 
concepts  to  the  systems,  a  top-level  description  of  needed  capabilities  (i.e., 
initial  capabilities  document),  and  definition  of  the  CONOPS  for  those 
capabilities.  Prephase  A  begins  the  capabilities/requirements  evolution 
strategy  and  activities  to  develop  and  manage  the  requirements  and 
documents,  (sec  2.2. 1.1. 1.1.,  p.  22). 

The  key  aspect  of  this  phase  is  that  it  is  forward  looking  to  technology  maturity 
and  capability  development  in  the  form  of  hardware  design  and  build.  This  means  that  all 
the  activities  are  primarily  planning  and  analysis  based,  resulting  in  documentation  and 
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direction  for  future  development  of  hardware.  This  brief  summary  is  sufficient  at  this 
point  to  provide  an  adequate  context  of  understanding  for  the  rest  of  this  study  without 
describing  the  remaining  aspects  of  the  DoD  JCIDS  process. 
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APPENDIX  B.  DEFINITION  OF  TERMS 


This  study  makes  repeated  use  of  terminology  that  needs  to  be  defined  in  order  to 
create  a  common  understanding  for  the  reader.  The  concepts  discussed  here  are  not 
intended  to  establish  new  definitions  in  the  larger  acquisition  community  but  is  strictly 
focused  to  guide  the  reader  to  understand  the  intended  meaning  behind  commonly  used 
phraseology  in  the  following  chapters  and  sections. 

Typical  or  Standard:  Used  to  indicate  that  a  particular  systems  engineering  process  is 
articulated  in  a  published  and  established  text  viewed  by  industry  or  the  military  as  a 
standard  or  reference  text. 

Tailored:  Used  to  indicate  that  a  typical  or  standard  systems  engineering  process  has 
been  changed  in  some  form  or  implementation  from  that  which  was  originally  described 
or  defined  in  the  original  source  guidance  text. 

Effective:  Used  to  indicate  that  a  particular  tailored  standard  process  or  unique  process 
implemented  was  advantageous  towards  the  overall  goal  of  completing  the  SASSA  rapid 
acquisition  as  close  to  the  ideal  as  defined  by  a)  the  original  baselined  delivery  date  of 
October  2010;  b)  the  original  baselined  cost  estimate  as  defined  at  contract  award  and  c) 
the  baselined  functional  and  performance  capability  defined  in  the  government  technical 
requirements  document  placed  on  contract.  The  antonym  of  this  phraseology  will  also  be 
utilized  in  this  study  to  describe  SE  processes  implemented  that  have  the  opposite  effect. 

Success  or  Successfully  Implemented:  Used  here  to  capture  a  judgment  that  a  particular 
tailored  or  unique  SE  process  implemented  in  the  SASSA  program  significantly 
contributed  to  the  current  state  of  the  SASSA  program.  In  this  study,  all  SE  processes 
implemented  that  positively  contribute  towards  meeting  the  goal  of  the  rapid  acquisition 
are  deemed  successful.  There  is  an  inherently  subjective  nature  to  this  type  of  judgment. 
As  such,  in  all  cases  possible  there  will  be  a  quantifiable  justification  made.  In  other 
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cases,  this  will  not  be  possible  and  will  have  to  rest  on  the  logic  of  the  case  made  for  a 
positive  contribution  to  completing  the  SASSA  program  on  its  ideal  objectives  for 
schedule,  cost,  and  capability  as  defined  in  the  contract.  The  antonym  of  this  phraseology 
will  also  be  utilized  in  this  study  to  describe  SE  processes  implemented  that  have  the 
opposite  effect. 

Acquisition  Product:  Used  here  to  capture  the  complete  set  of  resulting  products  of  an 
acquisition  program.  This  includes  all  hardware,  software,  study  results  and  analysis,  and 
resulting  experience. 

Rapid  Acquisition:  Used  here  to  denote  a  contractually  obligated  acquisition  effort  that, 
relatively  speaking,  attempts  to  complete  either  a  typical  amount  of  “acquisition  product” 
on  a  compressed  schedule  or  an  above  average  amount  of  “acquisition  product”  on  a 
typical  schedule.  Typical  here  is  a  subjective  judgment  for  what  appears  to  be  standard 
for  the  industry  of  space  acquisition  and  at  the  Space  and  Missile  Systems  Center  (SMC). 
For  example,  it  is  not  typical  to  deliver  flight  hardware  in  two  years.  This  would  be 
considered  an  aggressive  schedule.  To  deliver  two  fully  integrated  flight  payload  systems 
with  space,  ground,  and  testbed  segments  is  very  A-typical  for  the  space  acquisition 
standard,  including  at  SMC. 

Program  and  Project:  In  the  standard  sense  of  definitions  derived  from  standard  SE 
guidance  texts  programs  and  projects  are  different.  The  Aerospace  Corporation  SV  SE 
Handbook  provides  these  definitions  where  “a  project  is  an  effort  with  a  specific 
objective  and  end  point.  For  example,  a  project  might  be  to  develop,  launch,  operate,  and 
dispose  of  a  SV.  By  contrast,  a  program  is  an  ongoing  effort,  without  a  defined  end,  that 
may  involve  a  number  of  projects.  GPS  is  an  example  of  a  program.  In  common  usage, 
these  terms  are  often  used  interchangeably.”  (p.  21).  By  the  standard  definition,  SASSA 
is  a  project,  but  is  referred  to  in  common  usage  as  a  program  in  this  study. 
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Payload :  The  term  payload  is  used  here  to  denote  a  set  of  units  on  a  larger  satellite  space 
vehicle,  which  function  together  for  a  specific  purpose.  Satellites  often  have  primary  and 
secondary  payloads. 

Spacecraft  or  Bus :  This  term  is  used  to  identify  the  elements  of  a  satellite,  which  are  not 
the  payloads.  It  includes  the  flight  computer,  power,  attitude  control,  solar  panels,  etc. 

Space  Vehicle :  This  tenn  is  used  to  define  the  spacecraft  plus  payloads  on  a  satellite 


93 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


94 


LIST  OF  REFERENCES 


Acquisition  Strategy  Brief.  (2008,  March).  Self-Awareness  Space  Situational  Awareness 
(SASSA)  Program. 

The  Aerospace  Corporation  TOR-2006(8506)-4494.  Space  Vehicle  Systems  Engineering 
Handbook  (2006,  January  31). 

Analysis  of  Alternatives  for  the  Space  System  Attack  Identification  and  Characterization 
Capability  (2001,  March  22). 

ANSI/GEIA  EIA-632.  (2003,  September  1).  Processes  for  Engineering  a  System. 

Babcock,  Charles.  (2009,  December  17).  IBM  Rational  Tools  Aid  Smart  Device  Makers. 
InformationWeek.  Retrieved  June  2010,  from 

http://www.informationweek.com/news/services/saas/showArticle.ihtml7articleID 

=222002448 


The  Chairman  of  the  Joint  Chiefs  Of  Staff  Instruction  (JCSI)  3170.01C.  (2003,  June  24). 
Interoperability  and  Supportability  of  Information  Technology  and  National 
Security  Systems.  Retrieved  June  2010,  from 

http://www.opengroup.org/gesforum/uploads/40/4537/CJCSI_6212_01_C.pdf 

Commission  to  Assess  National  Security  Space  Management  and  Organization.  (2001, 
January  1 1)  Retrieved  July  2010,  from 
http://www.DOD.gov/pubs/space20Q101 1  l.html 

Congressional  Unfunded  Request  Language.  (2007).  Self-Awareness  Space  Situational 
Awareness  (SASSA)  Program.  Courtesy  of  SAF/USA,  United  States  Air  Force. 

Covault,  Craig.  (2007,  January  17).  Chinese  Test  Anti- Satellite  Weapon.  Aviation  Week 
&  Space  Technology.  Retrieved  July  2010,  from 

http://www.  aviationweek.  com/ aw/ generic/ story  channel,  i  sp?channel=space&id= 

news/CHIO  1 1 77.xml 


Defense  Acquisition  Guidebook  (DAG).  (2010,  February  19). 

Department  of  Defense  Directive  Number  5000.01  (2007,  November  20). 

Department  of  Defense  Directive  Number  5000.02.  (2008,  December  8)  Enclosure  12. 


95 


Evolutionary  Acquisition.”  Defense  Acquisition  University,  Acquisition  Community 
Connection.  Retrieved  June  2010,  from 
https  ://acc .  dau.mil/CommunityBrowser.  aspx?  id=2442 1 

Evolutionary  Acquisition.”  Defense  Acquisition  University,  Acquisition  Community 
Connection.  Retrieved  June  2010,  from 
https  ://acc .  dau.mil/CommunityBrowser.  aspx?  id=2442 1 

IEEE  1220-2005.  (2005,  September  9).  IEEE  Standard  for  Application  and  Management 
of  the  Systems  Engineering  Process .  Institute  of  Electrical  and  Electronics 
Engineers.  A.k.a.  (ISO/IEC  26702) 

INCOSE-TP-  2003-002-03.2.  (2010,  January).  Systems  Engineering  Handbook,  v.  3.2. 
The  International  Council  on  Systems  Engineering  (INCOSE). 

ISO/IEC  19760:2003.  (2003).  A  Guide  for  the  Application  of  ISO/IEC  15288. 

Jumper,  General  John  T.  (2004,  August  2).  Foreword  to  Air  Force  Doctrine  Document  2- 
2.1,  Counterspace  Operations.  Retrieved  June  2010,  from 
http://www.dtic.mil/doctrine/jel/service_pubs/afdd2_2_l.pdf 

Military  Standard  499B.  (1994,  May  6).  Systems  Engineering. 

Request  for  Proposal  (RFP).  (2008).  Section  M  &  Attachment  CD-4:  Integrated  Master 
Plan  (IMP).  Self-Awareness  Space  Situational  Awareness  (SASSA)  Program. 

The  Space  System  Attack  ID  &  Characterization  Capability  MNS  (2000,  June  27). 

Systems  Engineering  Primer  &  Handbook  (3rd  ed.).  (2005,  April  29).  The  Space  and 
Missiles  System  Center  (SMC),  Los  Angeles  Air  Force  Base,  United  State  Air 
Force. 

Technical  Requirements  Document.  (2008).  Self-Awareness  Space  Situational 
Awareness  (SASSA)  Program. 

U.S.  National  Space  Policy.  (2006,  August  31).  Retrieved  June  2010,  from 
http://www.fas.org/irp/offdocs/nspd/space.pdf 

USSTRATCOM  Joint  Capabilities  Document  for  Space  Control.  (2006,  July  28). 


96 


INITIAL  DISTRIBUTION  LIST 


1.  Defense  Technical  Information  Center 
Ft.  Belvoir,  Virginia 

2.  Dudley  Knox  Library 
Naval  Postgraduate  School 
Monterey,  California 


97 


